10 ReactJS tips and tricks you need to know as a frontend developer.
React has made communication between the client and server side easier. The concept of components and data patterns used by React enhance the performance, and make our code easier to read and understand. Support for JSX syntax, Virtual DOM, code stability and SEO friendliness make it the most popular JavaScript framework. So it is pretty clear why a frontend developer would prefer React, thus we move on with 10 extremely useful React tips and tricks every frontend developer should know.
1. Use functional components
Previously there were two choices for defining React components, the first being React.createClass() :
And the other being ES6 classes:
React 0.14 introduced a new syntax for defining components, as functions of props:
This is by far my favourite method for defining React components. Apart from the more concise syntax, this approach can really help make it obvious when a component needs to be split up. It’s important to note that functional components have a few ‘limitations’, which I consider to be their greatest strengths. The first is that a functional component cannot have a “ref” assigned to it. While a ref can be a convenient way for a component to look up it's children and communicate with them, my feeling is that this is not the most efficient way to write React. refs encourage a very imperative, almost Jquery like way of writing components, taking us away from the functional, one-way data flow concept for which we chose React in the first place.
2. Fragment shorthand
The React fragment has saved us from having additional DOM elements lying around, but the shorthand can save you a little bit of time and space at many places in your code.
// Long
<React.Fragment></React.Fragment>
// Short
<></>When using the shorthand, just make sure that your linter is set up to not show errors for using it, or that your formatter incorrectly treats the shorthand and creates a random jumbled mess out of your code.
3. Always use propTypes
propTypes offer us a really easy way to add a bit more type safety to our components. They look like this:
When in development, if any component is not given a required prop, or is given the wrong type for one of its props, then React will log an error to let you know. This has several benefits:
- It can catch bugs early, by preventing silly mistakes
- If you use
isRequired, then you don't need to check forundefinedornullas often - It acts as documentation, saving readers from having to search through a component to find all the props that it needs
4. Name your components
To figure which component has a bug, it’s important to always give your component a name. Even more so when you begin to use React Router or third party libraries.
// Avoid these notations
export default () => {};
export default class extends React.Component {};There is a debate about whether to use a default or named import. Note that a default import doesn’t ensure that the component’s name is consistent in the project. Besides, tree-shaking will be less effective.
No matter how you expose your component, name it
You need to define the class name or the variable name (for functional components) that’s hosting the component.
React will actually infer the component name from it in error messages.
export const Component = () => <h1>This is a component</h1>;
export default Component;// Define user custom component name
Component.displayName = 'My Component';
5. Use Redux
Redux is a predictable state container designed to help you write JavaScript apps that behave consistently across client, server, and native environments and are easy to test.
Redux is mostly used as a state management tool with React.
With Redux, the state of your application is kept in a store, and each component can access any state that it needs from this store.
6. Keep your logic out of your JSX
If you’ve got some logic going on in your JSX, whether it is a callback or the rendering of some elements, defining a separate function can go a long way for readability.
7. Keep your components small
The smaller your components, the easier they are to test and the easier it will be to keep your components focused on what it is they should actually do. If your components starts to get large, reassess the logic and see if you can’t move some of that into utilities, hooks, or even break that component up into smaller components.
8. Omitting a prop value defaults to true
Just like writing an attribute with no value for an element in HTML defaults to true, omitting the prop value for a component will default to true.
The React documentation shows that both lines below pass the autocomplete prop as true.
<MyTextBox autocomplete /><MyTextBox autocomplete={true} />
9. You don’t need super() in your constructor
super() is called inside a react component only if it has a constructor. For example, the below code doesn't require super:
However if we have a constructor then super() is mandatory:
If you’re not doing anything with your props in your constructor, you can safely omit super() from your constructor.
10. Components don’t neccesarilly have to correspond to DOM nodes
When we first learn React, we’re taught that “Components are the building blocks of React and they take in input and return some UI descriptor “. Does that mean that every component needs to directly return UI descriptors as we’re typically taught? What if we wanted to have a component render another component ? What if we wanted a component to manage some slice of state and then instead of returning a UI descriptor, it returns a function invocation passing in the state ? What if we had a component that was in charge of managing sound rather than a visual UI, what would it return? What’s great about React is you don’t have to return typical “views” from your components. As long as what eventually gets returned is a React element, null, or false, you’re good.
You can return other components,
render () {
return <MyOtherComponent />
}you can return function invocations,
render () {
return this.props.children(this.State)
}or, you can return nothing.
render () {
return null
}
