A Real World Example of Functional Programming with fp-ts - Frederick Fogerty - CityJS Conf 2020

[Music] hello everyone and welcome to the talk i wish existed three months ago why three months ago well let me run you through a little story i've known about functional programming for about three or four years i had experience with haskell and f sharp and i've dabbled in other languages such as purescript but i had a pro a project coming up about uh three months ago that i wanted to use functional programming for i thought it was a great project and i thought let's dive into it the thing is it was a typescript project and i had no experience with that writing functional code in javascript or typescript and let me say the learning experience wasn't great and i wish this talk existed three months ago to give me a helping hand first a little bit about me my name is fredrick fogerty uh i'm a software engineer at imogex uh and there i have the the fortunate role of overseeing a lot of uh sdks a lot of different languages a lot of different projects were in different languages and frameworks so i have a pretty good view of the land um they're based in san francisco right now i'm in geneva switzerland um and i'm hoping that next time we we have this this conference that i can make the trip to london and give it to your own person uh and so my promise to you by the end of these 30 minutes is that if you're someone who doesn't really know what functional programming is you're going to have a good understanding of what it is and why it's important and if you're looking to actually dive in and write some functional code in typescript with the library fpts then you'll have a better understanding of how to write actual functional code not just what a monad is all right so in this talk i'm first going to briefly go over what fp and fps fpts are there kind of benefits and why you should use this functional programming paradigm that is so popular and gaining popularity uh every day it seems and also what the pros and cons are of using fpts specifically um and then the second section i'll be going over an ad prefactoring and with this i'll be taking a existing application in javascript and converting it to a functional style and hopefully with this this is for the people who want to write actual fpts code uh you could have a deeper understanding of how to reason about functional code not just read an example and try copy that example all right so functional programming first what is it well the analogy i like to use is that to explain to people who have written javascript already and have tried typescript that when you go from javascript to typescript you're essentially adding data contracts to your code base so what you're saying is this function returns this data and this function consumes that data and the type system can help you ensure those contracts are compatible and then if you change your contracts the type system will help you out and say hey look you should probably change the other thing as well to make sure the data flows around your system correctly for me one of the benefits of functional programming is now we extend this contract to not just include the data but the behavior and how that affects your application what that means is instead of just saying this function returns this data now we're saying this function behaves in this way this function can throw an error it can maybe return a value these kinds of things is asynchronous and then when this other function consumes it the type system will help us ensure that those function contracts are compatible some other benefits of functional programming is that you end up with code which is more isolated and testable and why this matters is because when you're writing oop a common thing is you kind of have to force yourself to write good isolated testable code with dependency injection and things like this and it can seem like you're just pushing a ball up to the top of a hill and it's kind of teetering that up there and then at any moment it can kind of just roll off what's a term that is thrown around a lot of the industry is a pit of success and functional programming is commonly seen as one of many pits of successes basically by writing your code in a functional style using a functional framework like fpts you don't really have to do much effort to make your ball roll down into the pit and you have a more a better program as a result and you don't have to do too much work for it it turns out that with functional programming i like to think of there being three pits of success there's isolation correctness and testability in this talk i'm going to be giving you an understanding of why of how the kind of correctness uh of success is relevant but for other pits of successes what i recommend you do is go watch this talk by mark seaman uh call the pits of success he has some great explanations in there and you can see it's an hour long it's well worth the time and also any of the other talks are also amazing seriously go watch them they're great now a bit about fpts it's a a typescript library which has 5k styles on github and it's the biggest functional programming library that implements haskell esque types this is not like random or low dash this is implementing types like ethers and task eithers and don't worry if that means nothing to you yet hopefully it will by the end of this talk kind of leading on from before i like to think of functional programming having the benefits with things that can fail and also it helps you write this code because it's replacing it's kind of built from real world code it wasn't just made up kind of theoretically these two things allow you to have a much better experience when you're refactoring your code because if you can have these contracts these behavior contracts and also the fact you're running less code means that when you're refactoring you have less stuff to check that is correct and also the type system helps you ensure that the stuff you are moving around uh is working together behaviorally so if you move a function underneath another function which throws it which returns an error state you have to handle that and a functional programming paradigm forces you to do this but it doesn't it doesn't make it complicated don't worry about that it also helps with validation isolation and testing it makes functions more testable a downside for me is that typescript wasn't really made for functional programming i'm not to say that they're not doing the best they can but when you have a language which is designed for functional programming like haskell the benefit's going to be much more significant than in a language like javascript where you're kind of just putting it in there it wasn't designed for it but i still think there are benefits to be had um and what i think is that if you do like functional programming when you try this out in javascript i would suggest to you to try out another language like purescript or haskell briefly and see if it's worth making the complete switch obviously it's a bigger investment but i like that you can try out functional programming in javascript with no real cost and for me the biggest the biggest downside is your qa team might not have any work to do you're going to write less bugs and then your project manager is going to come along and say hey give me some bugs so i can give it to the qa team in there and uh they can they can review them and fix them and they're not going to have any work to do because functional programming is going to force you to write more correct code we've briefly gone through what function programming is and what fpts is and its pros and cons and i want to slow down a bit and take you through the main part of the talk which is talking about our application uh this is a real world example it's not a to-do list or just a simple like theoretical example i think this example combines enough complexity with database calls asynchronous work and business logic to give you a understanding of what writing actual functional code uh is like in in typescript so let's dive in what our application is going to do is it's going to be an airline reservation manager and it's going to handle a reservation request from the client so the client will pass a reservation request to the server the server will validate this json request essentially and will return a 422 if it's invalid if it is valid it will try and accept this reservation which means that it has to go to the database get the existing reservations for that flight if there's enough capacity on the plane uh it will save the reservation and return onto a one otherwise if there's not enough capacity it will turn a 403 what that looks like in code is this you can imagine this code's running in a sort of functional um server uh on on a server somewhere on node.js server and this is the first line this is the function contract and what i want to point out here is the promise the return type so we're returning a promise and inside this promise we have an http response but the thing is we all know promises can be rejected but we don't express this in our type system so we have no way of knowing when we consume this function uh whether it's going to fail or not maybe we read the documentation and we make a best guess when we're writing code that's consuming this function or consuming any promise and we code it kind of with this assumption uh when we write it but then down the track um or even because the documentation's incorrect this promise could reject and we could end up with a function that errors at runtime because we just haven't considered all cases because we there's been some issues on the way now i think you kind of have two ways to solve this one is that you can write code defensively so you end up with just try catches or dot catches everywhere on your application and this just leads to kind of wasted code for things that you know can't fail and the second way is you kind of just trust it and hope for the best and add like a catch all in the the top level of your application but i think um this is kind of a little bit of a cop-out because you can do much better if you can handle uh the errors where they happen and if you know where they happen and you can do this easily we're going to find out how we can do this with functional programming so first thing we do we validate the request that came in and if it's not valid we return a 422 if it's valid we try and accept that reservation by sending it to this tri-accept method and the reservation manager and then this function is going to return either undefined or reservation undefined if it fails if there's no capacity and so we handled that undefined by returning a 403 otherwise we returned to a 1 to say that the creation succeeded the reservation was saved successfully now let's dive into the try accept method this is where a lot more happens so here we're saying that we're taking a reservation request and we're returning a promise i'll look at the function contract here again because now we've kind of indicated that this function can error but we're representing this as an undefined type and that to me that seems like a bit of a hack to me it seems like we could lean on the type system a little bit better to help us along and indicate this is actually an error in an error state maybe you think of returning an error type instead but then the consuming code gets messy it has to check instant solvent things like this it's not the best we can do better than this but for now let's look at this function so first we get the reserve seats for that flight from the database then we check if there's capacity if not we return undefined as i mentioned and if the capacity is sufficient we can create a preservation cool so that's a first look through the promise based code and i want to draw attention to an aspect of this code that can be improved um with a library uh that comes with fpts i could do a great i could i could go through and talk through this but i thought i'd leave it best to an existing talk by robin paconi who explains this concept extremely well uh in seven minutes validation and honestly you should go check it out it's awesome um yeah it's type functional programming and type scripts with fpts back to the promised base code so you're probably wondering fred why did you write from what write the code in a promise-based style well i was thinking for a long time about the best way to create this deep mapping uh intuitive mapping between code you already know and familiar with promises and functional programming because i believe with this mapping then you can go and be more empowered to write functional code yourself with a better deeper understanding of it and sometimes you have to go backwards to go forwards so how i'm going to relate this promises to functional programming is you can think of promises as being a framework when you write normal code you kind of say okay let's pass the data around and you pass it then around yourself manually then when you use promises instead of passing the data around yourself you just tell from promises what to do when data exists so you say you call these dot then calls and then you just trust promises the promise framework to pass the data around for you and then if an error happens you trust the promise to handle that error and execute either the next catch callback you've registered or just reject that whole promise so to illustrate this in code and how this maps to function a functional style with fpts i've taken the code for the tri-exit method you've already seen and just reduce it down to the promise backbone what we can see here is we're getting the reserve seats again and then we're chained with.mit.dan message callback onto that promise and the same code written in functional style actually looks quite similar on the right we have the same code written in a functional style it's probably a lot to take in at first but let's dive through it piece by piece so first we're going to look at the return types on the left we return a promise as normal and on the right we're returning this thing called a task either this is something fpts provides for us and you import it like so and what a task either is is it's a combination of a task and an ether a task you could think of as a promise some asynchronous code that never fails always succeeds and you can think of an either representing either a failure state or a success state and when we return a task either it's not going to return those that error or that success state directly but it's going to wrap us wrap it in this type which we can then use use other functional programming functions which are given to us by apts to handle this newly returned type pretty seamlessly so back to the code now let's look we've looked at the return types now let's look at the function bodies so what i want to point out here on the left is that we kind of take a promise that's returned from get reserved seats and we chain a dot then call onto this promise as i mentioned before but the key thing is a key difference between functional programming and promises is that that promise is created for us and we just kind of use it it's different in functional programming because we construct that framework for a function ourselves manually because we want to have control over what type we use i've shown you a task either and there's many other types which i'll get to at the end of the talk but for now we're going to use a task either and we can think of this do function that we also import from fbts as a constructor we're constructing this task either type and then we're chaining stuff onto that which we've constructed this is probably a lot to take in so far and there's more to come so prepare yourselves and there's gonna be a lot of learning in the next few slides but we're going to go through it very slowly so this is the same code as before but fleshed out a little bit more we're going to walk through this step by step what you can see is probably added in this slide is these strings reserved seats and reservation results this is another difference between promise based code and functional programming where in promises the data is passed down to you directly downwards so it's the result of one dot then call is passed down to the the parameter of the next stop angle passed down one by one by one functional programming works slightly differently and that you can treat these as variable assignments you can think of this buying reserved seats as we're going to do some computation and save it in their assertive seats variable and then we can the task either will pass this around for us and functional reporting will pass this around for us and we can use it wherever we want such as in the return return call at the bottom by the way the dot binds and the dot bind l and return these are all come from functional programming they're not the dot binds you're used to so for reserved seats the variable assignments what we do is we call the skip reserve seats method and we save it say the result of that in the reserve seats variable now i'll take a pause here and uh give you a big tip for when you're writing function code yourself is that always check the types match i talked about these behavior contracts and that was for a reason we need to make sure when we're writing functional code that the functions we call and the framework we have pushed into uh always match so how do you do that well in an editor like vs code and many other editors you can just hover over this method call and you'll see that uh the method returns a task either and so uh they're matching the same thing both task eithers ignore the te that's just an important thing next we're going to look at the reservation result this is where we do the business logic so we consume that reserve seeds variable which we just saved before and then we're doing some business logic again we'll check if there's enough capacity if not we create this error and then remember what i said about we can't just return data we have to wrap it in a type so we're wrapping this error that we return in a left type from this call and then if there's enough capacity we will just create the reservation and we'll check again uh that the types match and they do um this is a task either type so we can just return that directly now let's take a look at what it looks like to consume this function in the original api handler so we have this function and what i want to focus on first is again the function contracts i sound like a broken record but honestly it's important in this function contract on the first line we're returning a promise again like before we haven't changed anything i think this is really important that you can when you're starting out with functional programming you isolate the functional aspects of your application from the rest so then the consuming code is nonetheless this means that first your colleagues don't have to learn what functional programming is they can just use your code as normal and secondly if you want if you're experimenting with functional programming you can more easily take it away after the fact without having to change a lot more code it doesn't affect the rest of your application and so how we do this is we take this task either and we we pass it to this function called promis from te on the second line and that will just convert a task either to a promise it's really quite a simple function and we can and this will be included in the code examples which i'll look at the end of the presentation so as before we construct this task ether type and then we do some computation and we save those results in variables so we first need to validate the request that comes in from the client so we do this by executing some code and saving in reservation request what does that code look like well we now have this new method called validate reservation request which will return a task either but the thing is this will return just any old error it doesn't know about us wanting to return http codes so we have to change the error type and we do this with this function called change error type which again will be in the code examples this comes from fbts and that means that if this validate reservation request fails uh we'll change the error type to a 422 and before passing it to kind of a task either backbone which will handle the error itself and return it to the client and if it succeeds we don't do anything we just let the result pass through and be saved in the reservation request variable next we consume that reservation request in the next bind where again we pass this reservation request into the tri-accept method as before and then we want to change the error type because again we don't want to return that error it gives to us we want to change the error to be a forbidden and so that will be returned to the client if it succeeds we can just uh pass it on to the return uh call the end and since we don't care about the actual result of the try accept or the reservation that's returned we just return it to one that's what we do in the last line that was a lot um now i want to say something at this point uh if this didn't make sense if i if we went through it pretty quickly and which we did it doesn't make any sense don't worry about it at this moment what i think you will have understood is that kind of intuitive mapping between how promises work and how functional programming code is written and that's what matters the code the specific code does not matter and what i suggest you do is if some of this didn't make sense i will link the code examples from the from this talk at the end of the talk and uh you can play around with this in your own editor on the editor i provide and kind of hover over and see the types and maybe change some code and see how that works and play around with it there and kind of get a deeper understanding for it but for now i think we should crack on um and i mentioned that one of the benefits was refactoring and i want to show how that looks like and how the type system helps us out so let's imagine we're changing this try accept method from just accepting a capacity as a number to accepting a function that returns a task remember we can think of a task as a promise that never fails so what that looks like in promise based code is we have the parameter capacity which is a function that returns a promise and then we consume this by changing another dot thing call on to the existing promise chain uh and we call this git capacity but that's past the parameter and then you can see the ugliness of promises where uh we have to pass this data around for us and this is where the benefits of fp buy because all this this uh do construction because it passes data around for us and what this would look like in a functional style with fpts is this is the tri accept method with the change parameter uh a function that returns a task and we would pass it in uh with a bind call and save it and try save it in this capacity variable now you could think i could probably just call this function and it will work for me unfortunately uh the type system will yell at you uh it'll give you this kind of cryptic error um actually it says that the first line task is not assignable to task either and at this point uh especially for writing functional code you'll start to say is this really worth it am i am i really getting anything out of this and you'll probably look at stack overflow for a while um and you you might lose some hope but please don't lose hope because the solution is really simple remember what i said before about us having to make sure the the types match well uh if they don't match there's helpers that fpcs gives us which really makes it easy to to convert types from one to the other so since git capacity returns a task and as before i mentioned that a task either is just a combination of tasks and either we can actually easily bring up this task into a task either and make it compatible with a helper method that's given to us from fbts there's the import call and we just called te.fromtask we passed it that getcapacity call and it's going to handle the the changing of the types for us and for consuming code it will look and feel like a task either but under the hood it's actually a task then as before we consume this new variable in the reservation result by adding a key to the the parameter list and there's no other changes cool so that was a quick refactoring and i hope i can show you i showed you how the type system helps us there by pointing out where that behavior was incompatible if we'd written the same code in promises and say we passed we tried to error um add an error handling handler for that with a catch for example the type system wouldn't help us out at all we'd be essentially writing extra code that needs to be maintained and reasoned about when understanding that function which doesn't benefit us at all because this capacity function can never fail and so typescript helps us out because it stops us writing that extraneous code and tells us hey look this can succeed always succeed don't need to worry about it there's also a benefit here that if we consume some code say from a library it gets a lot harder to reason about what that code does because you didn't write it so you don't know if it's going to fail or not how they handle errors and things like this and fpts makes it super easy because we can just see what the developer intended and the type system will help us when we're writing it but also in the future if the developer who writes a dependency changes how that code works typescript will tell us hey look now this thing can fail with the error like before uh with this kind of error and we can lean on the type system to help us out here anyway uh let's look briefly um at the other things that fp offers i'm not going to go through this list but in this talk i've only talked about tasks and tasks either but there's lots of other fp types which i'm which are super useful some of them have javascript equivalents some of them don't and this is really where the benefits of fp with correctness start to come up because you can represent lots of different kinds of behaviors in your application with these types and then your code becomes a lot more correct because as a consumer you know exactly how these functions work you're not just assuming all right so to close this out i want to talk about two things firstly i want to talk about what you can do right now uh and from today onwards so you've watched this maybe you've watched this talk uh and you're thinking okay i know a bit more about fbe um and i might use in the future uh but if you're a person who watched this talk and says great i i see this code and i want to write fpts tomorrow what can i do well what i recommend to you is uh the best scenario you could be in is that you have an upcoming project just like i did which you could work using fp for so it could be a project that's sufficiently complicated maybe has some database calls is asynchronous maybe has some i o or just things that can fail what i suggest you do is you earmark this project to use fp4 and then you will write code for this project in an isolated manner which doesn't affect the rest of your code base using those function contracts and then you can evaluate it with that the second scenario i think that you could be in is maybe you don't have an upcoming project but instead you um are maintaining some code and uh maybe you have some code that again is complicated enough can fail has daily db calls these kind of things uh what you can do is start to refactor some of that code into a functional style and you'll probably start to see there's places where code can error and fail the ways you didn't expect and you will end up improving that code just by refactoring it into fp and lastly i want to remind you of the big picture here why is fp important and at the start i mention these things with the pits of success today we've only had a time to talk about the correctness pit of success you have to take my word for it that these other pits isolation and testability really do help you write better code especially if you're working in a tdz style but maybe you'll write code first and then you test afterwards if you write code in a functional style you'll find that testing that code becomes super easy rather than having to refactor it after the point if you've tried to do this you understand uh what i mean with testability and again if you are interested in these pieces of success i recommend you go watch that talk by mark seaman functional architecture pits of success it really goes into this in a lot more detail but the purpose of my talk was to give you an example of real world code in typescript and i hope i delivered on that promise for you and then you now have more confidence in writing real-world functional code in typescript with fpts a little bit about my company i just want to mention them i work for imagex what we do is we will take images from where they're stored on your server uh we allow you to change them using your parameters and then deliver them to your users as fast as possible um i also personally like the company uh they're the team uh everyone on the team is super smart and um also driven to to improve the product and work together as a team and they're really good team players and if you're interested we're offering a chance to get three dollars of credit um in this country at this conference so uh please come to our booth and have a talk to us uh and otherwise um i'll also be there if you wanna come talk about this talk and yeah that's been my talk and i hope you've enjoyed it and please enjoy the rest of your conference thank you very much [Music] hey frederick thanks for that that was amazing thank you so much it's a pleasure to give this talk um yeah it's great i think functional program is one of those things that everyone is forever interested in but is often kind of uh impenetrable gets weirdly academic so it's great to see that kind of accessible and real-world approach to it rather than um something a bit more up in the air um so for everyone that's in the chat um if you've got questions uh stick them in the q a panel we'll put them to frederick uh i'm i'm glad to say there's none at the moment which means i can ask you my questions which is why i was asked to go over it um i was curious with the the like typescript and functional programming seemed to work really nice together do you think like strong typing and functional go hand in hand or do you think there's some flexibility there um pretty much yeah my overalls will be here since you know when you shift from that type script or type kind of typing type system up to a functional system you get those the main benefit is the behavior contracts this is kind of what we're really going for and so when you're developing you can lean on the type system to help you out that is really the main benefit when you you code in a language like javascript um and so i think in in javascript world yeah they kind of go hand in hand but there are other opportunities to use function programming without static typing closure has no static types and still has a lot of the benefits of functional programming and also if you kind of want to just go for map juice like the lower dash render kind of style functional programming which is a little bit different that also works without typescript but for this kind of specific variety you know of of functional programming you need to need a system for it and it also gives you all those nice um like id integrations where you can you can get good suggestions um you showed off some of some of the like typing support um is there anything like is there anything that beneficial from fbts in terms of other dev tooling uh sorry what was the what was the first product question you said so you you mentioned that in vs code you can get like uh your type definitions when you hover over a hover over type um is there any else is there any other nice like dev tooling that comes through with uh fpt uh unfortunately i wouldn't say so and i think there was a part of the talk i kind of referenced robin's talk about validation and this is something you can see either of my code examples which i'll post afterwards or you can go watch this talk about what that does it's not really dev tooling it's a runtime thing basically it will ensure that any data you pass to it say in my example the api handler it will validate that reservation request for you to a very strict data kind of structure and it does that very very seamlessly i will say and so that's i guess the one of the biggest benefits but yeah the the main one is the is the ide support and then of course the type system that's cool uh so we've got some questions coming in so um sure any tips on solving the problem of leaving behind code that future devs might not be able to or want to refactor yeah it's a good question i'm just reading it again over on the right hand side um so i think uh this kind of goes back a little bit to uh one of my my closing thoughts which was i think a really good candidate for functional code is code that is um kind of prone to complexity lots of errors database calls asynchronous this kind of stuff um i think if you're kind of worried maybe about um delta's not willing to kind of maintain that code i think you should really start with the places where it's going to have the most benefits and then you know the best scenario is that they're going to to look at it and and go okay this is actually a lot cleaner than i would have to do um would be able to write myself and javascript and they'll kind of see the benefits of it but if you're just writing a hello world example or functional code or something like this they're not going to intuitively understand it um if you've used a library like rxjs before which kind of does the same thing but for reactive programming you also kind of understand what i mean that if you write if you have to write like a you know like an auto complete or something with normal javascript code that's a complete pain and with rxgs it just makes it obvious and i think this is the kind of thing which if you write it for a complex uh area a complex part of your of your of your code base it will just make sense and then that'll be the best chance for other devs to want to maintain it in the future so this is like the hook to get them into functional you leave behind leave behind some functional code in the code base the breadcrumbs and they come from the dark side exactly sounds good to me yeah um so the next one have you tried other fp to js languages like reason ml and rescript i haven't um i [Music] not because i i could have had a look at them um but not because i don't think they're valuable it's just because i want to maintain a high amount of compatibility with my team um and so if i were to i think with any big decision you have to make is how it's going to work in your organization and if i were to kind of campaign for using a um a language like this uh it's not popular it doesn't have much support uh it's not very stable um uh maybe there's some good up issues or something like this outstanding and so that that that campaign becomes quite weak but if i can stay inside a language we already use and just write parts of it in a more functional style it's not so hard for them to kind of get up on board there and it actually leads to a experience across the whole team which is really what i'm going for i'm not you know i don't adopt these technologies to make my life better but to make the kobe right better and my teams go better yeah so yeah yeah i think um kyle like alluded to this yesterday with the the talk you gave where it's not it's not like all or nothing you can start using some some functional approaches throughout your code like i imagine probably all of us are using all of the es6 like functional bits from es6 already without really thinking about it and actually we can start bringing more of that in as we go so it's not kind of terrifying um like jump ship straight into something else yeah exactly i think you definitely have to be quite pragmatic and um boring dare i say dare i full functional program boring but it's boring enough if you do it in typescript that it's not going to be a big issue hopefully yeah so i think at the beginning of your talk you mentioned um you'd had experience with i think haskell and fsharp um yeah yeah back in the day yeah okay yeah do you think that made it easier for you to jump into this like do you think learning the kind of functional bits in a serious functional language was a better approach or do you think maybe actually is a javascript developer this is an item i would say it definitely helps me yeah definitely help me because in those languages you have no option and also they um because you're writing because those languages designed for you're writing less code there so the learning curve is almost easier because you have less to understand like if there's just less characters on your screen there's less there's less stuff going on that you have to understand so that helps you learn differently um and it did help me learn this library but i will say that um i don't think it's necessarily any easier if you wanted to start learning functional programming uh with strategy typescript i think you could also have a good experience um and this is really one of the reasons i created this talk was you can kind of come from it from a theoretical angle but i think it's also really useful to have a real world practical example which you can follow on with say if you watch this on youtube again afterwards uh and code along with it it will start to that's the idea of it that makes sense yeah yeah totally yeah um i think you've it's one of those things i've put off fiddling much with typescript but i'm a big i love functional programming like i played around with pearl and high school quite a lot i love them and i'm now um chafing a bit to jump in and play with fpcs it feels like a good intro to both of them and um yeah like two birds one stone type thing um so another question from essan was is it possible to do something like promise all with fpts yeah there's a straight um comparison if if you look on one of the last slides of my um on my talk i had a comparison of types and javascript types so there's two ways to do it um you have kind of a straight uh i just pretty much straight uh i could swap to this thing called sequence t that's all right sequence s which will complete these tasks or task either simultaneously which is what promised to haul does and returns an array there's also another type which works very similarly except it executes all the tasks and tasks it does simultaneously but stores the result in an object which can be nicer depending if you want to uh to do it that way that's really cool yeah um i'm curious i assume you're using this when you work was this what led to this how did you find like bringing the rest of the team along with you with starting this this new idea if it's if it's the first time you've used this in your code base that's a great reason i guess we can all play this talk to people in our teams to explain yeah um unfortunately um i did i did childhood talk recently but um i some what some of them had experience with uh high school not many uh real world experience but at least kind of theoretical experience and so that was a big leg up um otherwise just walking through the code so i think it's really helpful to have someone alongside you to say you know you look at this and you go what the hell is this thing and then you go okay let's break it down slowly it looks like a promise it kind of works this way uh and then having someone there just to ask to answer your questions so i just sat down with my my colleagues and said hey look let's run through this if you have any questions let me know and we can talk through it um awesome it sounds like all of us will be jumping onto fpcs and dragging our teams with us which is a good thing um thank you so much that was amazing talk uh i really really enjoyed it and thanks for joining us um so we're gonna switch over no no of course um actually next talks about dino uh for anyone in the chat um i have a couple of exciting updates so all zero running a well all of the speakers are running these competitions if you go around you can get a secret code and you'll get into a competition to win uh some books and some t-shirts um also also running what what they've tantalisingly said to me is a login challenge which i'm fascinated about uh and you've got the chance to win a 75 pound amazon gift card and there's five of those so you've got quite a good chance to win uh so feel free to drop in there um but maybe let's head back to the blacktail channel for the rest frederick again thank you so much for your talk and i'll speak to you later take care

Channel: Pusher

Views: 7,333

Rating: 4.7380953 out of 5

Keywords: developer language, language code, libraries, help, tips, forum, meet-up, meet up, learn code, coding education, coding hints and tips, lecture, coding lecture, learn about code, learn a developer language, amazon alexa skills, developer conference, node.js, javascript, backend, functional programming, monads, functors, Applicative, TS library, fp-ts, js

Id: -U9HQembktY

Length: 46min 29sec (2789 seconds)

Published: Mon Nov 02 2020