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.
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.