Tried & True Tips from 25 React Experts to Make You More Productive

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.

Understand JavaScript fundamentals. React is moving quickly towards a more functional, hooks-focused future, and the more you understand the fundamentals and how JavaScript works, the easier the transition will be as you work with React while it's moving in this new direction!

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

I have been writing code for about five months and, if I may add, with some help from the Stack Overflow community. I have learned a lot in this period and now working mostly on my own. I write a lot of pseudocode as it helps me understand the syntax and logic of what I am trying to build. I use TypeScript primarily rather than JavaScript to enforce type safety. If you are using TypeScript, learn to respect the interfaces. Finally, to write more clean and confident code, use linters such as prettier and eslint. Doing this, I not only stopped writing terrible code, but also learned from my mistakes.

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.

Make sure you have a healthy understanding of JavaScript itself. Don't skip the fundamentals of React, it has a lot of flexibility, and like anything with flexibility, that can work for you or against you. Understanding the fundamentals and the common ways those fundamentals are applied will get you further than anything else that I can think of. The React documentation is wonderful, so take the time to dig in and know it backward and forwards. Once you have a good familiarity with the docs, choose a couple of leaders in the community that you connect with, and focus on learning from them in the beginning. Focusing on just a couple of people will help eliminate conflicting information that may come from leader overload. One of my personal favorites is Kent C. Dodds.

Master JavaScript itself. Most devs probably think this advice doesn't apply to them - I thought I knew JavaScript too, until I started trying to read & understand the source code of React and other libs (i.e. what better way to master React than read the source?). I'd highly recommend Eloquent JavaScript and the You Don't Know JS book series for those looking to really master core JavaScript. And after that, start ripping apart React's codebase piece by piece and see how it all works under the hood.

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.