Using Hooks and Codegen | Tejas Kumar

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
hello everybody how are we oh my gosh you know I have to say I I wish you could see how beautiful you look from this stage oh my goodness it's incredible the diversity in the room I can feel the attitude that wants to like learn and participate in this amazing community and I'm honored to be here today to share in that my connection was lost this is exactly what I was afraid of let's see if we can restart things here technical difficulties I would tell you a dad joke to fill the time but as usual I can't think of one there we go all right so as I was so lovingly introduced my name is Tagus that's pronounced like contagious in the English language which for those of you who aren't familiar with the Indian name that's a quick mnemonic for you and it is not Tejas I get that so much here and understandably for Texas and things but no it is stages and I work at a company called con te amo in Germany actually flew 14 hours across the world to be here and share in the joy that is the react community with you today thank you at con te amo we have used react for years and we love it we also use graph QL and it's just an amazing family of libraries and JavaScript based tools that we use and enjoy but I have to say the greatest joy at my work is is this I work alongside some of the most brilliant people I've ever met in my life and it is just an honor to be with them they we laugh we cry we get on each other's nerves sometimes but you know it's like that everywhere right but unfortunately that's not what we're here to talk about today we are here to talk about rest and not just rest but rest and graph QL and stuff and I spent I spent a lot of time thinking about you know how to structure this talk in a way that's engaging and in a way that can impart some of the knowledge that we've kind of amass over the years of working with react and graph QL and I think the best way to do that is to tell you a story and this story is one where you know it's based on real-world use cases that we've had and things we've heard in the community and like any great story it starts with JavaScript um we we love JavaScript we use javascript and we're thankful for JavaScript now we have built a product that was built entirely in JavaScript this was before even the react days this was back in backbone and it was a really great product we loved it our customers loved it it was useful and helpful and for many years that was how we you know that was a product we built over time though what ended up happening was our product we kind of lost confidence in the ability to refactor it we were afraid to delete parts of it we were afraid to rename things that we exported because heaven forbid we run into you know cannot read property something of undefined right or we can't we we couldn't afford to see any ends anywhere because we were like a data science company we still are and so numbers are important and eventually over time our JavaScript got old it we we end up having a lot of legacy and we wanted to refactor the legacy but for the reasons I just mentioned we couldn't effectively we were feature frozen against our will you know and so we decided much like many people here I've spoken to actually we decided to let's just rewrite things let's rewrite things with scalability at its core let's rewrite things to last and that's what we did and we did using typescript now there's mixed feelings in the room about typescript I'm sure and I'm looking at some of you and I understand it's it's new syntax right your reasons are valid it's there's new concepts there's generics and unions and intersections and should we have to deal with these things you know some would say yes some would say no but for us the benefits were actually immediately visible we could confidently refactor we could confidently delete and thing felt really good one concrete use case where typescript helped us was we had a design system and if you want to do something well it's your design system because it really underlies everything in your UI right it's your buttons your cards your icons and so you want the api's to be as transparent as possible you want the documentation to always be up to date heaven forbid there's a prop in there and it does nothing right we use a tool called react style goddess for a documentation and this is actually developed by my good friend Tom SAP again in Berlin and it is amazing because what it does is it takes of markdown file as input it will parse the markdown file and output a living style guide like it will render your react components if you have JSX code snippets in there it will actually like eval the code and give you like the components and the interactive code playground underneath which is a text area and if you change the text you know you're rendered components change so it's a really interactive thing in fact I'd like to show that to you right now so if we switch over here this is what our documentation looked like we have just a whole suite of components and all of this was generated just from the readme so if we look at button for example we have we have some text a title and this this is literally just generated from the source code so if I go to source here and go to button what you see here this markdown file it's just it's rendered here it's the same file and so our documentation comes to life we can further explore by playing so I could go button color let me just make it a little bit bigger color is red and if we zoom out we see yes it's red and I can in real time update this and it updates so it's it's this living thing the problem is if our documentation is out of date for example if I say prop that doesn't exist if this was from my documentation I I have no idea that it's broken right this is just kind of a it's kind of a lie early to people consuming this library now with typescript we can help this what we ended up doing was we the underlying editor from Visual Studio code the Monaco editor we put in the browser and used it in place of this text area we also fed it our type declarations from our compiled JavaScript from typescript and the end result is this this is the same source code from the same readme and if we go look at a button it's exactly the same but I click on this view code thing here and I get a rich text editor it still admittedly looks the same but look at this it says press alt space inside a component for available props and documentation okay let's try it and here I get a list of the props available to me to use what's more than that I can say color and I can give it like a red and it updates but here's the cool thing if I say invalid prop it actually signals to me wait a second that doesn't exist your documentation may not be up-to-date and this is one concrete way we're able to discover our own documentation library and keep it up to date this has added huge value to us where I work now I'd like to get into the technical details of this and show you more about how we did that but we don't have the time for that because this is about rest in graph QL there is another takata to react Finland earlier this year that is a bit of a deep dive into that and I'd recommend looking at that but the theme of the point I'm trying to make is that typescript has helped and we adopted typescript and we use typescript and our app was really really robust we haven't seen a run time exception in a very long time except at the network layer so we would have this app almost no runtime exceptions but every now and again sentry would send us Oh something broke and what ended up breaking was there the responses to data we would get so sometimes we would expect like an array and instead we would get an object with like numeric keys other times things would just be null sometimes things would like there would be breaking changes to the API that we didn't know about and our app would effectively blow up this of course led to a lot of bugs and quite frankly that made us really sad because UI developers we want to make it nice we want to not have bugs right I think that's a fair wish and so it's worth noting here that at this time we were using restful api as in fact we still are we have valid reasons to use them we just want to integrate with some other systems that work better in a restful architecture and that's fine but for our use case here with the UI unfortunately rest it's just not very good but if we're engineers we don't just say these things they don't just say it's not good done all right we we we quality qualify what we say and for that I will use a word that I wish we use more and a word I'd encourage using it's just not good because it's it's not a formal specification like it's it's just a convention there is no document that you can visit and say this is what it looks like when a restful api is implemented which then leads to a lot of guessing games right across both ends of the stack front and back and client and server well for example you know you send up a request to create a resource and it was created now does the server respond to you with a 200 status code because it's okay everything's fine or with a 201 status code because something was created huh well I guess no we don't guess how about this one if you try to access something you don't have permission does the server respond with a 401 because you're not authorized or a four or three because it's forbidden or just a 404 cause you shouldn't even know it exists I don't know and so it leads to these guests and games which ultimately culminate in meaningless discard I look at me III genuinely want to be positive about this but some discussions we have is engineers especially when DX does not facilitate good UX I would say are kind of meaningless what do I mean by that well I think if you're making an app for real humans with real problems you're trying to solve I don't think any of them stay up at night thinking what status code did that request use right like like if you make a medical app I don't think your your users and hospitals are thinking about if it's a post put or patch right we create apps for humans that are meant to give them value instead of discussing status codes and methods and lastly rest just has no contractual agreements kind of intrinsically built into it there are you know there's things like swagger and attempts to to create these contracts from which you can implement back in in front-end but there isn't something for more ultimately I think it's best summed up with this now I did not say this yesterday but I did say this at some point when I made this slide and this was an actus isn't like doctor anything's is an actual screenshot from an actual conversation that I had and I think yeah this is ultimately my response to this it's just like are you serious right now we have products to ship and so thankfully while rest can be not so good there's work being done in the space and there are other paradigms or client-server communication that genuinely help I would say graph QL is one of those I see Lee sitting right there thank you graph QL is very good and again we don't just make these statements without qualifying them graph QL is very good because exactly the opposite of those other reasons rich wasn't it is a formal specification it is like people have defined graph QL as a lot of things informally but if it is anything it is not merely a query language it is a live it like a specification that you can look at and say this is how the API is to be implemented and I think that is an absolute game changer for client-server communication you know what that does you know what that does react conf that removes guessing games you're no longer guessing or should that be a 403 or put Pat but know it's it's in the specification and if you have some edge case where you actually have to guess things it's an open specification meaning once you have a decision you could contribute it back to the spec and nobody else around the world has to guess and that means you can create the products that you love and you care about really really fast this then leads to meaningful discussions what do I mean by meaningful discussions instead of discussing status codes and what content type this request should be we discuss and we cash this can we lazy load that can we differ like we talk about things that directly impact our users and as a result create pleasant experiences that make the web altogether better and lastly I mean graph QL is built around a schema definition right and so there is a strong contract front and center from where you can implement your back-end and your UI these are just the developer experiences that that I'm talking about with graph QL they just the niceties of the DX if I was to talk about the UX benefits we would like have to go off the screen and then some graph QL and my experience in an our collective experience has just been a godsend and we're extremely thankful for it all that to say graph QL is very good but you know I spend a lot of time at a lot of conferences start a lot of people and I was one set I think it was a graphical conference and there was a talk an entire talk dedicated to how do you convince your boss to adopt graph QL I was surprised that this is needed to be a talk but okay and from the talk I got the impression that a lot of people have a hard time adopting graph QL it seemed to me like this is a conversation that was had quite a bit hi we want to add graph QL services to our stack well we can't because you know stuff and then we look at the because right and this is again this is gathered from various sources of hearsay we don't trust JavaScript from an AP for an API it's a JavaScript you know it's I mean it's it's it's single thread you know it's like you you have this like clock that follows the cursor around that's what you do JavaScript right you don't become on your new API we already have an API team and they have tasks I mean just open JIRA look in JIRA oh what's that JIRA doesn't work oh sorry no just believe me that they have tasks we just don't have the time for that right next quarter will do a funding round and we will focus on graph G I promise but we did like right now you know it's tight really we just need to ship we need to ship ship ship but when you ship like this you're working against the current because gravity will actually can increase your velocity at some point I've seen people react this way you know to these conversations and other times maybe your entire team reacts this way well what can we do about that I got to thinking and I was like well I mean I had an idea for a side project I have used graph QL for a while I love I think I think it's clear now how I feel about graph QL and you know I love the Apollo client and server and engine specifically like if you're here and you work on Apollo I would just even give you like a round of applause for it because Apollo is that yeah Apollo team Apollo is just an amazing suite of software client-server engine it makes the developer experience around graph QL so comfortable that then leads to nice or UX and so heavily inspired by Apollo I wanted to bring these benefits to rest but could it be done I think it could and so I created a library called restful react now this isn't some variation of react or anything it's just that naming things is hard right it's just it's just a library that fetches stuff on with restful api is in a more comfortable way at least to me and I'd love to show that to you right now so let's go over here and this is just a little react app that I built nothing nothing fancy it's just just one component that says hello react conf very creative and what we'll do is we'll use this library and it all starts with importing something called a restful provider so I will do this import restful provider from restful react and what this will do is it will give a little bit of context to the app I'm then just going to just like if you've worked with Apollo it's kind of similar I'll just wrap the app with this thing here and this is implemented fully in typescript so it's immediately going to tell me hey I need a base prop and base is the host the HTTP root of your requests so let's talk to one of my favorite API is in the entire Internet the dog API and so this is going to change absolutely nothing in our app but then we're going to go into app here and fetch data using restful react rest will react exposes hooks it's a hooks based library and so I will Const D structure something and I'll use the use get hook from restful react okay and use get needs one thing it needs a path where am I getting stuff from and so I'll do slash breeds image random I wanted a picture of a random dog because dogs make me feel happy and in the D structural what do I get I want and because it's typescript I have this autocomplete I want to handle error cases for sure I want to handle loading states and I want my data and so what I'll do is just relay that to the user so if I have an error I will hate one oops that's not a react component h1 and error dot dot message and if I'm loading same thing I won't use a spinner in this case I'll just go ahead and say I'm loading and then lastly if I have data I will IMG always remember your alt tags and I will data dot message and everything should be fine so now if I save this what we're gonna see is an image of a beautiful specimen and more and more and more now there's a problem with this though where it the app would break down at the network layer because I kind of just guessed this is what I'm getting back from the API but I could instead expect I don't know a massage you know and then well okay well not my app broke that's bad restful react allows you to describe the shape of what you expect from the backend using generic so I say I expect something that's a string and now immediately knows okay well you can't there is no massage the massage is a lie and because of that I get auto completion and my app is resilient and anything I do cannot really break them so this will fail at build time so this will never actually make it to the user as well so we've solved that but can we do better see if you remember earlier a few slides we said rest is just not very good because of all of these reasons right that last one is kind of debatable there are strong contracts in some cases they're just in the source code of your back-end API at contain our back-end API are implemented in go and go is you know it's typed so my coworker Fabian he's genius like his brain is you know anyway he created a thing that reads the goq API implementation extracts the type declarations and then transpires them to type strip and now this is done with a whole bunch of regular expressions it is incredible and it works that it's fully unit tested it's great but we wanted something that was scale a little bit better and so we started looking into open API which if those of you who haven't heard of it it's an evolution of swagger awaited document restful api and we had an idea well maybe we can use this you see they're meant to be human readable because they're JSON or yeah mole file and so you know that's why those formats exist is because they can be read by humans except if you thoroughly described a restful api you have to describe stuff forget post put patch 200 201 404 4 and it gets long in fact this is what it looks like in our code Bay and this isn't even the full thing so human readable sure what but we want to use it how can we use it so what we ended up doing was we found you know npm install' open api parser right there was a thing so we parse this document we extract it and we look at schema definitions for back-end responses we then take those schema definitions and write them to a api ts file and then we have because of this we actually have trans filed from an open API document end-to-end type safety but as Tom mentioned before we care about DX but also UX and the reason we did this was because the developer when the developer experience is good usually the UX tends to follow and I'd love to demo that for you right now let's go back here to our good boy and what we'll see is I'm gonna generate stuff from an API specification document I will open the terminal and restful react is also CLI that will do it for us so we'll say yarn restful react import the cool thing about this code generator is you don't really need access to this open API file on your file system it can fetch from github you literally give it your username a repo a branch and a file path and tell it where to put the final file and eventually it will do that so you just run the command and it goes to github fetches the thing returns undefined because I don't really we need it's open source and you to fix that you're welcome to contribute actually anyway so it's done we have ready to use things and if we look at it let's take a look at what that looks like so now I have a new file this green thing here API dot tsx and if I open it look at that it's just the giffy or jiffy api completely described here now I don't even need to look at this because it's it doesn't concern me but let's build a thing using this that can get data with end to end type safety from the jiffy or giffy which one whatever from from the API to do that we'll go swap out a restful base here we're no longer talking to this delightful API but we're talking to API dot gif feed content for or for understandable because gif he doesn't have this route just fine so we're going to remove the use get here we're also going to remove this and we will check this out this is where this is what makes me so happy I'll just import something from my API that I just generated and I will use the auto completion to see what's available to me now because of the rules of hooks we know that they start with what word use so let's use and these hooks here are hooks that will get me data from giffy just for free so let's try it I have a use random gift okay I'm just gonna pop that in here use random gift and it doesn't really seem to need any parameters and yeah it's just an empty object and look I'm still able to keep the error and the loading but data has changed look message is no longer a thing it's aware of what jiffy is going to send me this is amazing so instead of data I will just use auto completion data dot okay well there's another data let's maybe alias this too like gif responds just so we don't confuse ourselves okay and but you can see that this doesn't go in the SRC cuz it's not a string it's something else dot and then all of this from the giffy api just here statically how cool is that i want images dot notice how this question mark just appears that's because typescript has something called optional chaining if it doesn't exist it will just polyfill that to an empty object and you don't get can't read property this is undefined so let's go to I don't know I want the original size and I want its URL and at this point it is a string so this constraint is satisfied and if I save that I will have uh-oh what's wrong why I have an API key that I need to pass now you probably shouldn't do this just like share your API key at a conference I will I will revoke it after so that's fine you also probably shouldn't like yeah you shouldn't put it on every request cuz I just opened my network dev tools and I see your query parameter API key so maybe a little bit more thought here giffy but I will pass query params and I'll pass an API key of this pretend you've seen nothing when you saw nothing and I save and then we have a Ren n type safety what we have a random yes thank you and you know it's the entire API description so I could swap this out with I just maybe you're not a random one but I want to see what's trending okay oh maybe not because look look it's it's it's not it's not just a single image anymore it knows it so what is it what data in this case is an array of gifts so what I'll do is I'll go here and map over it haha gif response dot data dot map and I'll get a gif here and I will do that always use keys my friends gif dot we will use the ID as the key we will switch the alt text for something more meaningful the slug perhaps and here instead of gift response out of gift data doesn't exist but okay images does everything satisfied and what we have now is an array look at that just we could code an entire UI without ever leaving the editor and again we could just swap this out with use trending stickers I don't know stickers are cool I guess save and just like that we have spooky Frankenstein absolutely incredible so let's land this plane that was just quick demo of how we're able to achieve even with rest end and type safety in a graph QL world using tooling now I think the greatest stat I'd like to share with you is we before we kind of knew the potential of this we planned a feature right and then this feature we planned like a couple days for it because of the code generator we were able to get this done in minutes because we didn't spend time guessing checking it in the browser going back checking it we just coded according to our editor we just tab tab tab tab tab enter and we had a UI and with that let's talk take aways number one types or your I hope I've convinced you today that types are not all evil yes there are more flex concepts yes there's extra syntax but in the long run that can build apps that you're confident are up-to-date you have no problem refactoring or deleting code it can lead to more concise expressions of your product number two tests are amazing I didn't get to talk about them but rest will react thanks to my brilliant co-worker Fabio and team at Conti mo has an extensive test suite especially the code generator you know and so we're able to know that it behaves exactly as we expect it to and if it doesn't we just add a test and fix against the test and it continues to go I'd encourage you especially Kent Dodds is here testing JavaScript calm look at the app there is I think or someone a real Exim but testing JavaScript is great to make sure your app behaves the way it expects and we certainly enjoy testing the last two points are a little bit philosophical but that's just because I believe life's more than tech controversial I know nothing really is impossible potentially if you're if you're a software engineer you can do so much with code like working with imperative Dom API s was not really comfortable and so react exists and and it it has taken the world by storm there's another problem of getting you know doing multiple requests and things and so graph QL exists if there's a common pain point you have you probably have the capacity to solve it and I'd encourage you to get creative with your solutions because guess what when JSX came out for react was not was not well-received right like I think most of us in this room I certainly was like what why and so eventually though the value was shown and so I'd encourage creativity solving real problems while not talking about status codes and things I believe these points can ultimately create better developer experiences user experiences software and I genuine benefit the world around us ok thank you so much for listening I really appreciate the time
Info
Channel: React Conf
Views: 26,594
Rating: 4.8668251 out of 5
Keywords:
Id: cdsnzfJUqm0
Channel Id: undefined
Length: 30min 2sec (1802 seconds)
Published: Mon Nov 04 2019
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.