Take a "Contact Us" form as an example. I could just build the entire thing in one component, or it could be really decomposed: every text field is a component, submit button, etc .... How does one know how much form should be deconstructed and rebuilt as Components?
Connecting too many components is an issue that should be avoided when working in React and Redux. Having too many components connected to the state can cause things to go wrong with updating the data and how it gets displayed on the screen.
You'll see here that we have five components in our app. We've italicized the data each component represents. The numbers in the image correspond to the numbers below.
50 lines is a good rule of thumb for the body of your component (for class components, that is the render method). If looking at the total lines of the file is easier, most component files should not exceed 250 lines. Under 100 is ideal. Keep your components small.
I follow this rule of thumb: Three props is fine. Five props is a code smell. More than seven props is a disaster.
After a React component does mount, it will be listening for any React props or state that has changed. Once it detects something has changed, it will, by default, re-render the entire React component and it’s child components.
Here’s a basic example of how to use React shouldComponentUpdate. First I’ll start by creating 2 basic React components. In the images above, I’ve created 2 React components. One is a greeting component, and the other is the app component. Each React component is console logging a message during the render lifecycle.
Anecdotally, I would say that in practice my react components are somewhere between 50-300 lines in length, with the top-level components being the largest and most complex.
After a React component does mount, it will be listening for any React props or state that has changed. Once it detects something has changed, it will, by default, re-render the entire React component and it’s child components. Is it bad to re-render multiple React components?
My rule is to component-ize things that can and will be re-used in your app, either aesthetically or functionally. If this is the only form you need it is probably not worth the overhead of converting each element to a component. But if you will have many forms consider making components.
Example reasons to component-ize your form elements:
InputEmail
: does front-end validation for email inputs)SubmitButton
: always red, full width, etc.)In bigger projects I have worked on this has worked out well. I have a set of customizable form components so I can build a styled form with complex functionality. Usually it will look something like:
<Form onSubmit={this.handleSubmit}>
<Input default label="Email Address" type="email" validate={validateEmail} />
<Input default label="Password" type="password" />
<Button primary type="submit" />
</Form>
Form
performs general validation logicInput
runs a validateEmail
prop and renders the labelIf you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With