Getting hooked on performance and clean code
•Als PPTX, PDF herunterladen•
1 gefällt mir•198 views
The document discusses how to achieve clean code and good performance in React applications. It emphasizes naming conventions, single responsibility principles, and best practices to write clean code. For performance, it recommends code splitting, tree shaking, lazy loading, and optimizing re-renders. It also discusses tools like React Dev Tools and React Profiler to diagnose performance issues and optimize updates and rendering.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Getting hooked on performance and clean code
Ähnlich wie Getting hooked on performance and clean code (20)
Mehr von Seven Peaks Speaks
Mehr von Seven Peaks Speaks (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Getting hooked on performance and clean code
- 1. Getting Hooked On Performance And Clean Code Going off on a tangent with Denis Pshenov
- 2. Clean Code Easy to understand Easy to extend
- 4. Performance Fast initial render Fast responses to interactions
- 5. Performance Code splitting Tree shaking Lazy loading Fast initial render
- 6. Performance Fast render functions Rerender only when needed Fast responses to interactions
- 7. So is React slow?
- 8. Performance Flame graphs React Dev Tools React Profiler Diagnose & Measure
- 9. Flame graphs
- 11. Profiler
- 12. Why does React rerender? State changed Parent rerendered
- 13. What happens when React rerenders? 1. Run render function
- 14. What happens when React rerenders? 2. Update DOM
- 15. No state
- 16. useState
- 17. Does <Page /> rerender when we toggle the menu?
- 18. React.memo
- 19. Localize the state ✅ Single Responsibility
- 22. Global State Redux Context API Zustand ❤️ Jotai (or Recoil) Constate useContextSelector .. and a million more Options
- 23. Global State Zustand ✅ Single Responsibility
- 25. @dai_shi – Daishi Kato – our new favorite React developer (but we still love Dan Abramov too - the “creator of React” 😂) useContextSelector
- 26. Lists Unique key Virtualization (react-virtualized) ✅ Best Practices (by using linter)
- 27. useMemo useCallback useRef Other optimizations not related to clean code
- 28. Thank you! Become my Twitter follower #18 @ifeltsweet
Hinweis der Redaktion
- Hi, my name is Denis. I am a full stack developer currently living in the JavaScript ecosystem, which for me is mostly React and pretty much anything that runs on Node.js. Although I say JavaScript I really write all my code with TypeScript which I think is the pillar of good, maintainable code. I won’t go into my background because we only have 20 minutes and there’s a lot to cover in this talk, but if I had to summarize my experience I would say that after working with various languages and frameworks I think for me personally JavaScript ecosystem paired with TypeScript and React in particular for front-end is as good as it gets. It’s really cool when you can write your backend and front-end code in one language and maybe even a mobile app with React Native. And yes I know there are some problems with performance in React Native, but it’s a topic for another talk. In this talk though we are going to focus on achieving good performance with clean code. You might be thinking what is this guy all about. Performance and clean code are orthogonal concepts and they don’t related to each other. And I’m not going to argue with you but I like clean code and I like good performance, so I’m going to make a bold statement and sat that clean code can produce good performance and see how far I can get away with this. Shall we try?
- So before we begin let’s define what clean code means to us in the context of this talk. So for me really, clean code is all about whether it’s easy to understand and easy to extend so if a team member unfamiliar with the code base needed to make some changes he would be able to do so easily. That really is the primary reason why we are writing clean code.
- So there are many things we can do to write cleaner code, a few of them are naming, because naming is basically the only thing that makes your code understandable. I mean imagine a codebase where everything is named foo and bar and password is named username and username is named password. No matter how well you structure your code you want be able to understand a thing that’s happening there. The other thing is consistency – it is really important for the clarity and ease of use to do the things in a similar fashion, even if the chosen way is not the best way. Again, imagine a code base where each page is using a different button component for example. Now you need to support all of the variations and know how to use them all. Maybe it’s better to stick to one, even if it’s not the best in all of the cases. Single responsibility is really about making sure that a component or function is doing one thing only, that it has one purpose. And best practices depend on each area you are working with but usually they tend to focus on code clarity and things like linters can help with it. And I’ll actually try to demonstrate where a linter can improve your react performance.
- So performance is a broad talk but for the context of this talk we really only care about React rendering performance which usually comes down to two main metrics. How fast the initial render happens and how fast the UI responds to user interactions. So a badly performing UI would be sluggish and that’s something we want to avoid.
- So the way we would optimize for a fast initial render usually comes down to reducing the bundle size that browser has to download and then process. This is done with a help of a bundler like Webpack, but really any bundler that knows how to do code splitting and tree shaking and lazy loading will work. For all of this to work though you have to be splitting your app into multiple components, hooks, functions, etc, so that each page can import only a subset of the application code that it needs. This is where clean code concepts like single responsibility will help. So I guess we have somewhat established one connection between clean code and performance.
- So a sluggish UI can happen when the render function is computational expensive or your app is re-rendering either too often or too much meaning that it’s re-rendering parts that don’t need to rerender.