React Optimization Tips and Tricks - Time To React - May 2019

right so hi everyone I'm Eliot my talk is also on performance in react because we're hitting a bit of theme today hopefully this is going to be a bit complementary to the last one as opposed to conflicting about it's mainly gonna be focused tips and tricks kindness and low-level kind of implementation stuff I'm Elliot as I said I'm a full-stack engineer mainly front-end working a hyper exponential or HX are electrically challenged we are sort of a small fin tech startup working at Peckham we build frameworks for modeling and data science using sort of small fun quirky data sets that everybody uses nobody really talks about so generally yeah as I say we're going into some really low level stuff today things that you can actually use in your code and some best practices that might just been covered very briefly before so Who am I for about third time I'm Elliott I'm 22 I'm an imperial student sell for one more month my dissertations actually on the 17th so I don't have very long which is why I kind of have to apologize for doing this in PowerPoint at a front-end meetup that feels like a cardinal sin but I didn't really have the time to pick a Gatsby start a project with 4 stars and 40 open issues so I'm a full time full stack but mainly front-end engineer Bennett H X employee number one for about a year and a half I'm a reactant fuses first and foremost so at the moment I'm just turning all my components into hook space components even though that everybody says not to it I live on the wild side and I'm also a competitive rifle pistol and shotgun shooter because I don't do enough other things so key takeaways if you switch off now everybody's had a drink everybody's had some pizza you're feeling full and sleepy don't overload you're done every component should be pure fight me and every prop should have reference equality also hooks are great but that's not really in this talk they just are cool so how do you know if your components suck well if they feel like they suck right UX right if you're playing with something and it's really sluggish or if the whole page is going to freeze we have this component that's basically like an excel grid and and it's called the list table and I I was Devin on it and I was playing some large data and I was inserting a row and then the whole page froze for seven seconds oh I tried to load the page again that didn't work for seven seconds like okay I've really messed something up here and typically we can find that component stopped working because you know we test on its own and it's really fine and then we put an order of magnitude more on the page and it stops working and everything breaks and it falls over and we're not really sure why so we need to start working out how to do that and and how to work out why they're failing and as we said before chrome dev tools are really great I really like flame graphs again fight me but the the great things about these is you can actually you can go down and you can find okay I'm seeing that you know my my big list table component is updating and that's actually telling a hundred different list table cells all to update but I only changed one of them why is that happening so you can go in and you can prune it and you can actually see the results when you are optimizing going through and I really like the react dev tools extension because it's got this little thing where you can hit highlight updates and when you interact with all your components they get this yellow border around them which is really good when you're hitting a dialog and you hit submit and then you see all of the background on the page behind the dialogue flashes yellow and you go that shouldn't happen and so this is really useful for finding bad optimization patterns in your components so the big issue like I said with our list table component is just having too much data right I just need to show a bunch of stuff on the screen in this case it was every single cell in that grid was an input right they all had event handlers they all had methods sticking on top of them and it's a problem because if I see a big list of data I'm gonna do a map I'm just gonna go okay cool children map it I'm gonna put an item in there you know some sub component spread some props in it's great but everything that I put on that Dom is going to get rendered and if it's rendered it means all of its lifecycle methods and all of its hooks are going to get checked even if it doesn't repaint on an update check it's going to run all that render code it's going to run all that CPU time which starts to slow you down in an aggregate that really really sucks and what does this result in it's slow load times it's sluggish responses and it's really unhappy customers so TLDR lots of data and just throwing on a page is slow rendering and really bad UX so what's the solution well we just split the data up right let's just do the same thing but just show less of it right let's just paginate everybody plays with pagination before cool small chunks and on paper yeah pagination is great you know but if I'm a user and I'm on a web store you know and I go to Amazon I search for a thing and they give me twenty results back I know I want to see 60 I see all them I want to infinitely scroll you know that's really cool so why am I being limited by that because the developer doesn't want to handle that problem and so paging is very often part of the solution and it's typically a solution dealing with the network more than dealing with the front end it's very rarely the only solution and when we say okay I don't know how to do an infinite scroll or I I don't know how to deal with this Dom payload but and so I'm just going to implement a bad solution like paging only what we're really saying is that an implementation difficulty is guiding our design decisions which I really hate I I think if somebody says oh this is too difficult so we're doing a different thing that's wrong again you can fight me in the pub later so imagine if in the world where you only have to render the content that the user could actually see that's great right so this is a thing called virtualization where essentially you put a containing block on the page that could be the window itself it could be just some block in our case it was the the borders of the list table component and you you can combine it with paging as well so great so now we can show 60 things per page but we're only rendering the first twenty because that's all the user can actually see and so we're only putting those on the Dom those are the only ones updating so we've lost all this problem this exponential problem we have is now sort of order 1 and so HX internally we use great library via wrapped virtualized which by Brian Vaughn he's caught him at Facebook he's great libraries great use it but I'm not going to go super into detail on that because the fundamental principle is kind of what's interesting and you can implement these things yourself if you really want it to so should be diagram I know but the core principle is you have some containing element and if it is inside the containing element if the user can actually see it render it fully put it on the dom lifecycle methods interactions let people play with it and going around the outside you can put a render buffer in as I'd like to call it which is where you might show it you might even give it all the interactions so some of these Scrolls really quickly before the rend methods can kick in and throw new cells on that people can interact with it and people can see it and then outside that you might leave it blank you might just put some sort of standard HTML elements that are styled correctly and they look like there's data there but actually it hasn't got the interactions and the nested and the deeply complex components that you would normally put on that would clog up your DOM and another nice diagram to kind of see what I talked about here this is from a really great medium post when you get this light you should all check that this link it's really great on a guy just rolling his own but essentially if you have a list of stages this might be what you would see you know behind the scenes when you're just throwing everything onto the Dom versus when you're a virtualized right you're only showing what the user actually means so cool so we're dealt with just throwing data onto the screen what about the big problem that we've heard people talking about already which is react over rendering just a component updating when they really shouldn't and reactors going to do with this by default you do extens react up component or you're just going to use a functional component everywhere it's going to render more than it needs to and you know what 90% of the time that's fine react does some really cool stuff it runs its render function it compares the new Dom to the old arm and it goes ok cool I don't need to update and it doesn't do the repaint but again we're worried about that render time we're worried about running those lifecycle methods and in aggregate so we need to stop this and yeah it's really an issues but when it is and it's really is and when it was a big issue for us it was a big fix and I looked at I should have been doing best practices on the start I should have been coding so that this never became a thing as opposed to being a month sort of backlog which it was and that was at the minimum that was when the app wasn't very big and so in react we as politically are building a component tree right components have children many children and they have children and so if one unnecessarily updates and maybe a change as a prop right that might tell its children to update and I think unnecessarily update they tell their children to update and this problem gets exponential and so you really need to try and cut it as high as possible so first thing to do your components I love your components they're great essentially pure component or wrapping a functional component in a memo is going to compare your props and compare your state for the cost and or and it's only going to update if those props or steak have changed right and it's doing that by shallow basically reference to quality so you're not going into a list and seeing if the elements in the list have changed if the list length has changed or if the object contents have changed you're only looking at the reference or if the reference has changed which is fine this is going to solve a lot of your unnecessary renders but in practice it actually it solves kind of a few of them but if you've got bad prop passing patterns if you are doing a lot of bad patterns I'm going to go into then this isn't going to help because those bad patterns cut straight through pure component and react memo and I know what a lot of you are thinking I don't need pure component I use a component update everywhere again we can fight over this if you want but I don't think sure component update really is a use case aside from when you've got a proper component that's being passed fifteen props and you only care about three so the vast majority cases you should be pure component and should component update is kind of oh I'm not really sure I think I'll hack my way to a solution and so essentially I do this I pass bad props very regularly got it in production code you all are sitting there and I hope that some of you are thinking otherwise I'm clearly a very bad dev that you're passing bad props and so we all need to be more disciplined when we're passing our props so I do actually have some ducks and if you manage to answer the question then you get a duck so can anybody see where the problems are in this code yes that you would you like a duck there you are awesome yeah you don't get a second duck for that yeah so the first one is this object and the second one is this function we don't actually the title isn't a problem that's a strength string comparisons reference quality already that's fine same with the house family bill that's fine that's that's a quick check but the object every single time that this function runs that's going to generate a new object it's going to pass a new object to the child which means that the reference to quality fails new function passed the child reference equality fails so even if that child is pure component doesn't care that's breaking it and if this in this case if this on child clothes was raining all the time this will update and then it was child with update imagine you've got ten children in here exponential problem again oh no sorry they're just covered by the by the border yeah so maybe right we can solve this with classes right let's convert this to a class component and if anybody ever actually says that to you shoot them essentially yeah we could make this a pure component and we could solve the style by well actually our style here it's got the width which is coming from the prop so we can't do it in the render function anymore and we can't do it in a function and call that in the render so actually what we've got to do is we've got to put it in the state and then we've got to do use a lifecycle method and check if it's changed and then set the state and then use that and then we get some rudimentary memorization in our class components we could do this for the memorization you know library if we wanted to as well but we're assuming you haven't got that but for the function that's really easy right we just use a class method okay and if we use this class method this is going to get instantiated when the class is created and what so when the class is instantiated and then this reference is the same for the entire lifecycle of of this component cool right that's really simple well it's not because it's not using hooks and everything's better with hooks so if we were doing it as a functional component we could use hooks our close child is now a used callback hook which is only updating whenever on child clothes changes which is cool this is relying on the fact that on child clothes has got reference to quality because the hook comparison is going by reference quality but we're assuming that you're doing good patterns throughout your app and then the child style is a use memo which is a very similar thing I mean a use callback use a use memo that returns a function anyway and so that's only updating if the width changes and we're assuming here the width is a number so that doesn't actually matter you know it's it's only going to update when that changes so that child component is only actually gonna update when it needs to so cool we fix this component now a little bit of Redux for the people here who use Redux which I assume is a number of you yeah okay cool great there are a couple bugs here as well and can anybody see me bug which will cause some unnecessary rear Enders you get a duck I'll give it a little bit of time did I hear something you got a duck anyone Vicki anybody else yeah yeah so awesome okay you want a duck and Richard that's this job his job is here to duck people thanks rich so yeah there are two problems here right within your max safety props right max like props is binding new props to the thing okay so it's like you're passing it from a parent component it's just it's not coming from the parent okay so here every time that this max takes to prop front it generates a new list okay so we're breaking reference to equality again and that thing gets passed down and we've broken it Matt dispatched props doing the exact same thing every time that this runs it's going to pass a new function down and we've broken reference for quality again now you're thinking okay cool well my HRC's don't update all the time using redux every time that your state changes your hoc is rerun your state changes anywhere in the app it doesn't matter if it's not using user or if it's the dispatch doesn't change it's going to rerun these so you're going to get a new reference of quality past so you've broken reference equality way more often than this component needs to so we can fix this and it's really easy to do again this memorize function doesn't exist I'm assuming that you're using some library for memorization outside of a as either a function I've written this to look like a hook so people can implicitly understand it but essentially if the friend names prop changes or if the part of our stake we're actually looking at so this is really great it's instead of just going with state we're going with state user so if other parts change we don't care if either those change we pass a new friends object great this is the fun one didn't really know about this pattern cool one guy give them a duck so essentially what's happening here is we are taking the dispatcher and we are wrapping our action creator in the dispatcher in part on the props through and we're just spreading them through and this is such a common pattern Redux it's all over their Docs so everybody does it because you read the docking you got a problem okay I'll do that it's so common that that does the same thing except it does reference equality and so it just creates it once for the lifetime of this hoc and it never changes which is super great so we don't even need to worry about updates I will say if you use the second argument of this function you're going to need to do some memorization stuff you know if you use on props but I haven't seen anybody do that yeah so come to me with an example and we can chat about it and you might get a duck cool another thing I want to touch on if you see on on this one right so we're using friend names and we're building the friends prop from it right I imagine this is sort of a social media app like you're trying to show your list of friends okay and actually the sub component that this is being bound to you know that the HFC is wrapping probably doesn't need friend names anymore because I assume that the friends thing that's getting mapped to has got the name in it at somewhere so you probably don't need friend names so we don't want to pass it to the Commandant if friend names is updating all the time we don't want to pass that through we only want to care now with friends updates because that's super lovely and it only updates when it needs to so I do the same called prop filtering which is essentially where I will just have a buffer kind of funk your component that takes all of the props in that this component getting passed and I sit and I go okay actually what do I need and make sure that I only pass those because if you're using some context API somewhere in your passing some props down you overuse the spread operator like I do then you you you find yourself throwing in a bunch of extra props that you don't actually need and that component doesn't need but that might break its reference to quality you don't want stuff updating for we think that white folk thought when I shouldn't again you do this a lot and if you do it with 30 props then it looked super ugly and take 60 lines but otherwise it's great so thanks try to keep this short and snappy I was going to put up a bunch of stuff for a supplemental reading but you know Google's your friend there are lots of really great medium posts on optimization and performance and also you've just seen another talk really great talk on it and you can ask me in the pub as well but there is a really good textbook there helping you write react and that I will I will advise that you look out there so thank you very much Ivan Elia [Music] [Applause]

Channel: Pusher

Views: 41,814

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

Id: i9mMe7Esl7Y

Length: 18min 26sec (1106 seconds)

Published: Thu Jun 13 2019