React State Management In a GraphQL Era - Kitze

and I'd like you all to help me give a warm welcome about react state management and graph QL era Kitson alright here's this thing on we gotta start with some odd jokes like this one and this one it's a bad joke I know so alright this is a picture of me and react Amsterdam 2016 this was the first conference I attended ever two years ago I was a react noob like I was working with react for maybe I don't know a couple of months and I came to the conference I saw all of this amazing speakers on stage and now I'm standing here so that's like super crazy to me and I wrote my first medium article went back when I had zero followers I wrote this and I sent it to a friend who was pretty popular in the community he said no one will read this crap and actually people read that crap you know it was fun for them like a summary of the entire conference so what point am I making here let's talk about three terms ninja developer Rockstar developer and senior developer like I hate all of them ninja developer let's start with this one do you ever see a ninja doing webpack on a roof like at 4:00 a.m. ninja dude like they do ninja stuff right and then we have senior developer how the hell do you define a senior developer like for me this is the only senior developer that that can be all right that's the only one and then we have the third one which is like when you're standing on a stage and you usually hear people seeing oh he's a rockstar developer so I hate this one because this is a rockstar and this is everything but a rockstar alright there's there's the difference and you can hear sometimes he rocked the stage after a talk but the reality is he read his notes from made on a plane slides trembling for 30 minutes that people won't figure out that he's a fraud so yeah I'm trying to make a point that if I could make it here to this stage and talk to a lot of conferences you can make it to just try and talk about something that you're passionate about because at the end of the day we're all code monkeys trying to make weird libraries work together by writing shitty hacks thank you Thanks so that being said I think it's a rock star senior ninja or I'm kidding so I'm doing front-end open-source and I'm making some products lately I've been focusing for the last year on this project it's called react Academy Rio so I'm doing training and workshops for all of this technologies and hipster buzz boards that we use so if you need a workshop just let me know today we're going to talk about state management in a graph QL era let's start with graph QL like what is graph QL so it's the thing that's eventually gonna replace rest but you keep telling yourself that you don't need to learn like one day next month it's on that list that you have with libraries right so what is rest how do we fetch a bunch of data with rest we got to do all of these API calls right if I want to fetch a bunch of data I gotta do all of those calls and then combine the data on the client so you do the same thing with with graph QL by combining it into one query so actually you give the power to the client and the client can say hey I need all of these data so I need specifically this data and this is really powerful and flexible so in my opinion single page apps ruin everything because we were trying to make like a faster car but we ended up with that contraption whatever that is it's not a faster car so we put everything on the client just to make a single page app and I think that's really wrong so before I explain why let's talk about state management on the client why is it complicated right we have force we have routing we have inputs these are the small things that define state management on the client we have tabs filters date pickers menus checkboxes blah blah blah but the biggest problem it's not the small things it's data data is all he likes so that's the biggest problem that we have on the state management side all right day days thank you all right data is the number one reason why state management is hard all right I'm back to this apparently sorry here he is again and why is that because we have data fetching we have data caching we have reading and then we have cache invalidating which is pain in the ass no matter what you do so all of these four problems defined data on the client so my first single page app was written in jQuery that's me writing jQuery code so I'm not kidding you it still used in production maybe five years later it's used by the government so it's like one main.js file there's no webpack there's no input there's no build system nothing it's mange es unmagnified 3000 lines of code we have a bunch of code you have a calendar plug-in right into that file just saying calendar starts here code continues here like everything is in one file it was pretty terrible to write a single page app like that I mean it worked but you don't want to be the guy who is maintaining that hell right now and we were looking for a solution let's fix this jQuery mess and come up with something else for state management and of course I found out about angular 1 or nowadays they call it just angle or something and it was amazing for me because I liked it it it made everything simpler like state management and data fetching everything it made sense in my head coming from jQuery it was amazing until one day my roommate said like can you explain me that angular thing because you're really talking about it and I want to get into it you know and I said darn I'm like yeah it's pretty simple it's just a bunch of factories and you have services you can just inject the template that's a directive but it's also a factory and I'm like what the am I talking about like that's so complicated I know man this sounds wrong we got to move on to something else in my company after a while of doing angular we had the choice of doing angular 2 and then I saw typescript and I decided now we're gonna go with react so I won't dwell on how good react is we had a react conference easy I saved our lives is the best blah blah blah so when I started doing react of course I needed to fetch some data right so these were my API calls but I was trying to be too smart so what I tried to do is I built my own caching mechanism right like these are the smarter people didn't figure it out but I will figure it out on my own so I made a giant object where I store all of my data by key so those that would be the key and the data would be the value and that didn't work out well because after a while I needed to invalidate the cache I was like oh my god I got myself into a mess I need some other state management solutions I can put the data in it and of course you Google a bit you end up with this so I took maybe two weeks off from her work just to learn it and to actually grasp everything around and all the reducers all the egghead tutorials and stuff and I ended up liking it because it was recently than just doing set state back back in the day and the summary of it is right now I love Redux and I hate Redux I love it because it's a genius concept like if you haven't watched the egghead tutorial dan is recreating the library from scratch it's amazing you should watch it like it's a genius concept it has some nice ideas but are the underhand I hated because it's a lot of boilerplate to do something and it's not needed in 90% of the cases and if you trust men you feel good this guy hates redux how about the creator of Redux tells you that Redux shouldn't be used all right so he's saying here that it's definitely over five low level and often used unnecessarily and he literally wrote a blog post that saying you might not read redux so that's like Metallica releasing an album and releasing a blog post don't listen to our album it's like amazing how he can be critical about the usage of his own library that's amazing to me there was this example unready - hello reddit I just started my first react app what should I use to do my network requests and you won't guess what the first most up voted answer is who says just use Redux saga like who says just use Redux and no one says just use Phoenix saga that's like your friend is telling Huey there's a bug in my house and you're like oh I'll be right there with my bazooka for the bug that's like such an overkill for state management and right now there's a poor soul somewhere trying to connect Redux saga with Redux form just to make a freaking login form and it blows my mind like don't use it if it's not needed this was me explaining Redux to the same roommate we ran out we were in a restaurant and he was like look I have this idea for an app we're gonna make an app like we have a company of like 3040 people and everyone does the coffee for for all of them like every day or brings coffee so I want to make an app that's gonna shuffle all the names it's gonna pop out one name and that person is gonna do the coffee that day and he's like let's write an app on about having startup it's amazing and we were just joking around let's write the app and he's like okay index.html one main.js file we include jQuery we're done by the end of the day I'm like no no no and it Redux I'm gonna teach you react and redux and webpack and all of these amazing things he's just sitting there and I'm talking for two hours about how we can push a value into an array but we need four files and a reducer and the restaurant closed even the waiters was like what's the is going on in that code that's terrible and he got pretty turned off by the entire idea like using five files to do one thing and I said look it really looks complicated for simple apps maybe I should try this other thing I heard about it I'd react I'm sir them two years ago and it was mopix so it was pretty great I went home that night I learned mob acts it's pretty simple reactive programming observables and stuff and I liked it ever since then in most of my apps I have mob x included it doesn't matter if I have graphical or don't I like this solution better the point is what is better because we have this battles like since the dawn of time like jQuery vs mood tools angular vs M graph kill versus rest resources mob X react versus view Apollo vs. relay and so on and so forth so we have a lot of these battles right the mistake we're doing about all of them joining the last one is asking what's better instead of what's suitable for my app what's suitable for my team and what's suitable for our use case because asking what's better it's really wrong in my opinion I think the Trump is great but on a golf course so it's all about is terrible as a president right it's all about the context of the thing you cannot say this is better and what we have in our community lately we have this higher component suck on the other hand we have random props are everything why can't we as a community just find the middle and be like how about a healthy mix sometimes use higher order components sometimes use render prowl just don't say that one thing is the worst and one thing is the best it's all about the context then we had the same thing previously everyone was like up until a few months ago we need Redux for everything and then you see blog post like Redux is dead so we can just replace it with context no you idiots you cannot replace it with context because Redux is using context so this is really wrong like you can replace a portion of it by using the new context API you cannot just replace Redux it's a huge library so my point is find a healthy mix use Redux if you need it don't use it if you don't need so let's see data fetching examples we have fetch which is the simplest API we have five lines here to just fetch some data then we have redox I need couple of slides so I need an a sync action in order to fetch my to do this I'm dispatching a bunch of things but then I need to handle those actions so I have a reducer I have to do something with the data handle all of the actions that are gonna come and on our next slide we have the same thing in mob X we have one slide we have a class observables decorators a lot of things going on but it would be simple with graph curl so if we see an example using Apollo on the client to just fetch something from graph QL we can fit on one slide we can fit the component plus the query and that was amazing to me when when I saw like okay this component can just describe what does it need and it's it's coupled together right in the same component it was amazing because I don't have to do this call with Redux from objects or whatever else in the background this is pretty good the problem here is we were fixing the sink instead of fixing the well instead of fixing the root of the problem so the same could be we're seeing we were fixing state management and actually we needed to fix like REST API as we needed to get rid of them and replace them with something better and that the effect of that would be fixing state management on the client so this was state management as we described that previous the right data was a big problem and now if we remove data he's gonna be sad about it but we're left with bunch of small things for data now we can tackle this in like whichever way we want it's really simple to solve this there's no more caching and validating all of that stuff we were doing so an example of moving to graph killed is my favorite example I just showed everywhere when they moved from Redux to graph QL they removed around 5,000 lines of code like all of their they kept using Redux but they removed all the data fetching caching and validating logic and they removed around 5,000 lines that's amazing so you're gonna ask me the topic of the talk is do we even need a state management library when using graph QL and my answer to everyone always is like I don't know maybe you need it maybe you don't need it so I'm gonna give you a couple of examples of a stack that you could use and then you decided at the end of the talk am I gonna use it or am I not gonna use it so we have an alum ahead for okay I'm not gonna read them I'm just gonna start with the first one the first one is you can just use a client Sadler library like Apollo órale and you can use a router and set state and that's gonna be enough in most of the cases you don't need to include Redux from objects or anything external second one would be if you have like really complicated forms like a form in a nested form in a nested form or something then you can just grab a form library we have for make you have final form you have a bunch of them you don't have to install mob X Sarita just to handle forms right you can just install a form library then if you have like if you want to support off and queries and stuff like that you can just plug in specifically for Apollo you can just plug in Apollo cash persist and you'll get off line out of the box for the queries so you don't have to do it manually anymore and then we have I want to go home early which is Apollo malbec small box reactor for my box routers why do I call it I want to go home early because I remember this tweet from Michelle the guy who created our mob X he said mob X doesn't try to prove an academic point it just wants you to go home early but my advice is if you pay by the hour stick with redux you don't want to go home early and I like this deck I'm using it a lot and then we have a next level we're gonna use server-side rendering and probably you're not gonna lead need something for global state management on the client I like next yes for this example and now let me blow your mind by suggesting you this and people are going to be like there's no way we can do that how about use full page reloads when navigating between routes it makes you uncomfortable right you like your single page app because it so it's instant when I click it's instant but if you go to Amazon Airbnb a lot of these like huge apps they're not single page apps none of them is you click and you wait a little bit it's a full page reload and it goes to the other page and those pages are there like mini apps so this is a valuable approach because you don't have like a mega client side app you have a bunch of smaller apps and it would look something like this so for every route or no matter how you decide to split your logic you're gonna have a smaller app and that's more maintainable than a single page app that's huge you can also use only Apollo they released this Apollo link state so you can have client side schema so then your graphical library can also handle server queries but also client side stuff so for example if might reduce component needs to know about the counter that's on the client side I can just include it in my server query so I can grab some things from the server I can grab some things from the client but the beauty of this is my component will exactly will describe exactly what it needs like here's what I need from the server here's what I need from the client side State and that's everything that's gonna go into this component this is nice so when using graph QL in 90% of the cases you won't need Redux marburg's or sagas or observables or rx GS or whatever you're using if you still want to use it it's your thing so that's the next point I'm gonna make after this like we might to tell you what to do who is any speaker that gets on stage and why would you listen to us specifically for my example like you should know more about my context and how I work before you follow my advice about graph kill or anything else so let me tell you something about myself I work alone I'm doing the workshop things I don't work for clients I don't know what I'm doing basically I'm experiment with a new library every week and I'm gonna make a Christmas tree out of this slightly who does that and you're listening to me right all right thanks so before you follow someone else's advice whether it's a speaker where you see someone on Twitter on github whatever you should evaluate the context and your situation and specifically what you and your team are working on before you just blindly follow someone else's advice there is a client project story that I have for you before I jump to this slide we were we just started working with Apollo it was I don't know two years ago maybe we just started working with Apollo not two years ago one it doesn't matter we started with Apollo and I read all the docs and it held like the dogs are huge you gotta make like optimistic updates you gotta handle the cash perfectly you gotta handle a lot of stuff and I'm like this client has an MVP and their idea is gonna change like from week to week they want a new thing you know startups every week they're coming up with a new way to shake up the world so they were like we need to change this we need to change that and I'm like if we go all-in on making our code perfect like making our graph qlr Apollo and everything works perfectly we're never this team is never gonna make it because we're gonna go crazy there's changing requirements every week so let's do the minimum job that we can do and instead of handling the cash and stuff every time there's a mutation like every time a user is clicking like on something or is creating something new let's just refresh all the effective queries that are on the page right now and to some people you mean like oh you're gonna refresh data but that data was like less than a kilobyte sometimes it's like really small queries and it made it worth it because her team was more productive not thinking about how we're gonna handle the cash our responses from the server were instant and we didn't bother we could change requirements every week without a problem because we were only caring about what should we fetch not how should we cache it and we just refresh the data so the point is don't be scared of the network sometimes few kilobytes of extra data that you're gonna get are better than your team spending weeks on over over-engineering and making everything perfect nothing is gonna change anyway so just take it step by step I used to engineer things and now I'm trying to focus on the idea can I make my user happy because if you want to make yourself happy as a developer during your workday oh man that's so easy like you can get up in the morning learn what is redox saga redox form connect the to work for eight freaking hours to make a login form then when you go home you'll be like oh I feel amazing I learned these two new things but your user is gonna log in and he's gonna be like okay I can log in so you should see from the user side what did I do for this user today not what did I do for my developer satisfaction I feel like a genius because I made two libraries work together so just think about the user a little bit raise your hand if this was you in some situation I made something it works and I think it's awesome but I'm not sure if it's right right everyone literally everyone so we're looking for external approval I made this but I'm not sure what other people think about it that's why we have Twitter right but what is right guys we're putting HTML and CSS into our joss whedon like have you seen JSX what is what is have you seen webassembly like people are messing around with stuff all the time and that's why i'm starting to feel better and better about my code i'm like none of the other guys know what they're doing why should i care right so stop seeking that external approval for everything that you do I have this example this guy this friend I have made something with the react router he made something cool like a synchronously pre-loading when you go to a route it's finding all the link it's pre loading like it's something really cool and his app seemed instant I asked him why he didn't know why he's just made it like that's amazing like yeah it's amazing it works for me it works for our team but I'm not sure if it's right and what is right in the case if it works for you if you works for your team that's it's right this is connected to everything I talk about graph kill if it works for you and your team then it's right just don't seek the external approval like if you believe me I haven't used react router four or three or whatever they had after two because when I started with mob X I just built my own mob ax router that's been predefined for all of my apps and I don't know how to write anything which react out of four and I'm doing react workshops right and I don't feel bad about it because ma box router the thing that I wrote is pretty simple it's pretty small but it's satisfying my needs so I don't feel that fear of missing out what does the react router aap I do have this other example about learning new technologies if you know no model is the side it's written in PHP vanilla PHP no frameworks and jQuery so they don't have graph QL they don't have fancy state management it's literally PHP and jQuery and the interesting part is he's making around I don't know twenty to fifty thousand dollars per month like the sum of all of us here with PHP and jQuery and his brother started to learn development like at the same time and this guy the PHP and jQuery guy was like I'm gonna learn something just to make my users happy and to build a platform and his brother was like no no I'm gonna learn meteor and in the end of the day after a couple of Mines the one guy was rich the other guy knew meteor so that was the difference he was thinking of the users another example this same router friends we were talking a lot about graph QL and he's like man we took our graphical stack to the next level now we have like one caching layer on the server side and we have a pollo engine integrator we have a lot of things and on the client it's super fast it's like microseconds for responses and like okay are you building a new Facebook what the hell were you doing that you needed such a fast web such a fast API is that all we're just doing a landing page for hospital like there's not gonna be a case when the nurse says doctor we're losing here my landing page is not fast enough like don't over over engineer every freaking thing that you touch so you shouldn't feel bad like I don't want you to feel bad after this talk that you are not using graph kill using rest and I have an awesome point Sarah that was doing the website for react fast no first raise your hand if you haven't manually written a serviceworker or you don't know don't have any idea what they're doing right I haven't written one from scratch I know the one in create react up that I always delete like you generate a project which create react up and you delete the serviceworker but I don't feel bad about using it because Sarah made a landing page with a serviceworker and it turns out a lot of people visited the page and after that the service worker was like it it had all the data cache and it couldn't update the landing page anymore for their users so they had to buy a new domain just so they can resurrect users to the new domain because of a serviceworker my point is if you're using the latest and greatest graph QL in this case it doesn't mean that you're not gonna bump up into any problems to sum up the last part stop seeking external approval stop seeking answers in others people projects sometimes it's great to look into other people's project but don't do it for everything stop feeling insecure about your code because nobody actually knows what they're doing and the last one is hard but you gotta delete your Twitter account if you like what you're doing with your team with your stack whatever just forget about this talk and you can move on if you want to talk to me about these things you can find me online at kids head out and kids on github and kids on medium some tool kids on Twitter he tweeted once and he takes the account so I'm the kids on Twitter and badonk and taught C's thank you for listening thanks [Music]

Channel: React Conferences by GitNation

Views: 29,828

Keywords: conference, react summit, react conference, gitnation, react day berlin, javascript framework, javascript, react.js conference, web apps, react professional, reactjs, react amsterdam, software development, javascript talk, open source, javascript conference, react event, javascript event, react.js talk, dan abramov, react development, graphql, react, ken wheeler, react native development, javascript technology, react talk, react.js event, react advanced, kent c dodds

Id: Q54YDGC_t3Y

Length: 24min 0sec (1440 seconds)

Published: Tue Apr 24 2018