What are your top productivity tips (tools, shortcuts, practices, resources) you'd give fellow React developers?
Read on to find out what Emma Wedekind and chantastic had to say about asking the right questions and mastering the basics. You'll also hear from Kent C. Dodds, who highlights the importance of teaching and helping others as you learn. There’s also Kitze and Dan Wahlin with helpful perspectives concerning Redux - plus plenty more fantastic, high-quality ideas! So let's dive in. Take advantage of this resource - you are bound to find something to capture your imagination and experiment with.
Don’t try to learn everything all at once. Pick one aspect of React, such as render props, and learn it well by trying out different tutorials, by reading blogs, taking online courses, etc. Then reinforce this knowledge with small side projects. If you’re confused about something, ask questions. Chances are, someone else is just as confused as you, so you should never feel embarrassed to admit confusion. Practice a little bit each day. These atomic habits compound to ensure your comprehension of the library.
When you're first getting started on your app, spin it up with Create React App, and don't worry about making all of your decisions about what libraries you'll use upfront. People get stuck with "analysis paralysis" trying to figure all of that out when they could just be getting things built. Refactoring later is easy, you have a delete key, use it.
Learning the React ecosystem can seem really overwhelming. You might wind up spending the whole day configuring Webpack and Babel, or getting lost reading opinion pieces about different state-management solutions. I think that when you're just starting out, the best thing you can do is focus purely on “vanilla” React. The React team has done a great job making sure that its core API is concise enough to learn quickly, and powerful enough to build rich applications. To avoid the pain of build system configuration, you can use tools like create-react-app or CodeSandbox. When it comes to additional third-party dependencies, you might be surprised how far you can get without installing any! Ultimately, NPM dependencies are solutions to problems that the authors have run into. As you build your application, you may run into some of these problems, and discover the solutions that have been published. By doing it this way - solving one problem at a time, as they pop up - you avoid having to front-load a bunch of knowledge, some of which you may never need!
Looking for practical steps to get started building a vanilla React app? I wrote a blog post on the subject.
It’s been really exciting to watch React evolve over time and the developer tooling is better than ever. React Developer Tools like create-react-app are an amazing way to get started and keep getting better with every release. It gets you started quickly, and has built-in warnings for accessibility and other linting features that help you write better code. I’d also recommend not to worry about optimizing your React apps too early. React is a small library that already optimizes for speed. Choosing to use React on a project is a great first step toward building a performant application. Focus on speed when you have something that works and when you truly experience an issue, otherwise, worry less and focus more on learning to build cool things.
I have a friend who started learning React a few years ago and on the second day he called me and said: “This is super cool, but that Redux part is too hard”. Wait, what?! Redux is not a part of React. In fact, it might be the biggest setback that slowed down the React community. I cannot imagine how many beginners still fall for this trap and ruin their productivity by writing their state management with Redux instead of using just vanilla React. My advice is for everyone to try any of the better alternatives such as mobx-state-tree and Overmind before jumping to what was trendy four years ago just because some “gurus” said that immutability matters and Redux is a “clean” solution for state management. Stop wasting your time (unless you’re paid by the hour, then, by all means, keep writing five different files in order to push an item into an array).
Don't take the shortcut before you've gone the long way 'round. Shortcuts are provided at a cost. As a beginner, you can't know what that cost is and when the bill will come due. So get your fingers used to the long way. Master the basics — Components, Elements, Children, and composing them together. These things have stayed the same for years and are the key to understanding every trend in React. ESLint is a great tool but many presets exist only to antagonize developers. Don't use someone else's ESLint config. Make your own path.
For beginners: learn by creating a simple React application. Try to understand the lifecycle methods as you progress further. For mid-level: try to build a simple version of a web application without using React. And then compare it with its React version. You will have lots to learn, you will also realize that you don't always need React, or truly appreciate how React handles Virtual DOM, or only certain parts of the DOM getting refreshed on new updates. For experts: teach juniors and learn the underlying basics of React’s architecture, understand performance profilers, avoid unnecessary DOM updates, etc. My favorite is always trying to build a simple non-React version and avoid huge node_modules debt. 😊
React is a mature and mainstream technology. When starting, ignore the rich ecosystem that’s developed around it. Let React be a view library and study the abstraction as such. Take advantage of the fact that the core is small and the concepts are clear. Take the attitude of a maker and play with each building block. Build your abstractions from scratch and start over often. Allow yourself to understand what you’re working with. The hardest path forward is straight up the hill. Take your time — you’ll be glad you did.
Some people catch onto React more quickly than others, and that's totally fine! I was a slow learner. The good news is, there are a ton of great resources to help you learn React in a format that works best for you, whether it's text or video. And when you get stuck, there are plenty of people within the React community who are more than happy to answer your questions. Find your favorite course and just start learning, we'll be here for you!
Rule 01: Learn in Public!
If there's a golden rule, it's that all the other rules are more or less elaborations of this first one. Read more about “Learning in Public” on Swyx's blog!
One thing that I realized attending a lot of conferences is that you can find a lot of really great coding tips and strategies by watching people give talks. I know this seems like a “well duh” moment but it wasn’t for me. Beyond documentation, I was used to searching for solutions and going off of forums and tutorials, but conference talks tend to have richer content. Someone coding through a solution while talking about past hiccups and showing how they coded gave me so much more info. Sometimes while I make a meal I just keep a conf video playlist playing and go back to interesting points later. This may not seem like the fastest solution but the knowledge it gives me makes me more productive in the long run. Here are some good React conference playlists: React Conf 2018, React Conf 2019 ReactEurope 2019, React Amsterdam 2019.
Learn to type really fast so your fingers can keep up with your brain when your brain knows what it's doing. Train your brain to listen to podcasts/audiobooks at 3x speed. Make and use custom snippets. I have built a generator for common projects (generator-kcd-oss) and a toolkit that provides scripts for common workflows (like kcd-scripts). Know your dev tools for Chrome and React. Use tools like CodeSandBox to iterate on ideas quickly. Check out what hardware and software I use and my productivity page at kcd.im and try making a URL shortener (think kcd.im) to shorten URLs you find yourself sharing regularly!
Additional productivity resources from Kent:
React and the component model makes it possible to make reusable components. But not all the components need to be reused. The pitfall I see most often is that people are making components generic too early without understanding the use cases it will need to address. This can lead to an API that isn’t good and many unrelated props that are only used in some cases. It makes the component error-prone and counter-intuitively hard to reuse. A better strategy is to let people build many one-off components for their specific use cases. Then, figure out where the biggest pain points for developers are and focus on building a generic component for them. The process to build that generic component is to do a thorough inventory of those existing components with all the props, and try to come up with a well-designed API that works with all the use cases. It’s much easier to design an API when you have concrete examples to work off of.
My two favorite accessibility tools are
eslint-plugin-jsx-a11y, and the aXe browser extensions by deque. They are both great for catching the low hanging fruit and training you to look for those issues on your own. Looking deeper into the aXe resources, can teach you how, and why, certain rules should be followed. Getting started with accessibility can feel daunting, but you have to start somewhere. Remember, every little bit helps. Just get started, and keep going one fix at a time.
Don't commute, work from home, have a strict schedule, get off Twitter, get some exercise, and do the work!
Have a code playground: sometimes when writing code, it's nice to write it in isolation. My favorite is RunJS. It's a desktop app built with Electron. • Learn keyboard shortcuts for your editorA at my very first job, my boss said, “Why are you so slow when you type/navigate? You should learn to use the keyboard. You'll work a lot faster”. Since then, I've made it a habit to know the common shortcuts in my IDE and I've taken it to the next level and use the vim keybindings in VSCode. • Write a lot of code: the more you practice, the easier it will get. • Practice consistency: whenever you write code, be consistent. If you use one type of folder structure for your components, keep that style throughout your whole project and write documentation. Even if you're the only dev on the project, your future self with thank you. • Recognize patterns and use them: I'm not referring to your typical design patterns (yes, those are great), but things such as component structure, using hooks, etc. • Find a way of doing something you like, then make it easy to replicate. Use the React Docs and find people in the React community who you look up to and follow them.
Use the right tool for the right job when it comes to state management. Evaluate what the app truly needs rather than going with what the crowd says you should do. I think too many developers jump into “full Redux” when they don't actually understand it or necessarily need it. There are several other viable solutions out there. I personally use Observable Store as it keeps things simple, eliminates a lot of code, and is easy to understand by everyone on the team. Having said that, Redux absolutely has its place, but it's not the first thing I go to when starting an app. It's important to evaluate what your app will need before jumping in.
Use a tool like Storybook to build each component in isolation. Doing so provides a rapid feedback development experience. It avoids the need to navigate to a specific point in your application to see your component run. Storybook also provides a convenient spot to experiment with your component’s API. You can test passing different permutations of props and visualize the results. Storybook documents your app's components too. This encourages reuse, and aids onboarding. Finally, I recommend declaring a single mock data file for your app. You can use it for Storybook, automated tests, and a mock API.
Use Custom Hooks to share business logic and behavior between React Web, Native, and whatever. This is true “write once, use everywhere”. When writing a Hooks component, start with the JSX that you need to return. This will define what variables you will need. Then write a call to a custom hook that passes any props necessary and returns the variables identified by the returned JSX. And finally, write the custom hook.
Also, when contributing issues to OSS, use tools like CodeSandbox to give a repro case. This is invaluable for demonstrating a problem in the library by providing a concrete example that can be used to debug. Don’t just say “This doesn't work”.
Learn keyboard shortcuts for everything. This is vastly underrated. Spend the time to configure your editor and terminal properly. Embrace TypeScript, but realize it is a means to an end, not an end itself. Limit caffeine intake. Get plenty of sleep. Get really good at debugging and embrace it as part of your professional toolbox. When stuck, verify your assumptions. For example, are you editing the right file? Don't do hard things alone. If stuck, ask for someone to pair with you. Write mostly end-to-end tests and make them fast. Set aside 10% of your workweek to improve your skills. Becoming more effective in less time is still more productive than spending all of your time working at a slow pace.
Snippets are effective and allow you to generate common boilerplate and cut down on wasted time. Get set up with a decent linting configuration, it profoundly changed the way I code. Know your editor, VS Code is packed with features, to the point that ‘VSCode can do that?’ is essentially a meme. Learning shortcuts that empower and improve your workflow means less cognitive load. One of the important parts of building apps is what you do before writing a single line of code. Have a design to work from, be it a literal UI design or API spec, you should know it and be confident in the end product you are setting out to build. Good planning will flag edge cases, potential pitfalls, external dependencies, state flow and data handling policies just to name a few. Checkout Sequence Diagram, which allows you to visualize the data flow through an app and its interface and map out the state changes.
Since our purpose is to make fellow React developers more productive, the KendoReact team has one productivity tip of our own to add. It’s a matter of due diligence: before you dedicate months to building UI components in-house, check what your ROI would be if you included a third-party library of UI components instead. Chances are that in many cases, adopting such a tool would free you and your team to engage in more value-adding activities. With a third-party UI component library, you become more productive in at least two ways. First, by not having to reinvent a component that already exists, and instead implementing one that is ready to use out-of-the-box. And second, by not having to worry about maintaining this part of the code in the future. Taking it to the next level and choosing a commercial library with professional technical support, such as KendoReact, comes with the extra benefit of being able to essentially outsource keeping the components up-to-date with the latest framework and browser versions, accessibility guidelines and security issues, among others.
Thanks to Everyone Involved!
Now wasn't this rich collection of expert perspectives about being productive in React truly valuable? The credit goes to the 25 amazing folks above and their generosity in contributing to this resource full of best practices and React tricks. Tweet out your favorite tip and become a teacher yourself!
We’re sure you have your own special React productivity tips, so don’t be shy and let’s learn in public: share your favorite productivity advice with everyone in the comments right now.