React: How to properly handle component rendering using state variables

I'm trying to render different fragments onto a page in a sequential way (A > B > C), and am wondering what the best practice is in terms of using state variables to control the rendering of these components

Currently, I have it set up as a single state variable: const [screen, setScreen] and am applying conditional rendering:

  screen === 'page1' ? <Component1 />
: screen === 'page2' ? <Component2 />
...
: 'Page Not Found'

However, I am concerned this might lead to re-rendering of each component when screen is updated (or would this not happen because screen isn't passed into the component itself?). Would having a separate state variable to trigger each screen be more efficient? For example:

const [showPage1, setShowPage1] = useState(false)
const [showPage2, setShowPage2] = useState(false)
...
{showPage1 && <Component1 />}
{showPage2 && <Component2 />}
...

In general, I'm confused about how to reduce state variables and am wondering if clustering them together is a bad practice as it may lead to unnecessary re-renders. For example:

• Storing user data in useContext - updating one key updates the entire state and will likely trigger re-renders in multiple components
• Storing validation check and input values in an object to avoid having a state variable for each individual input

Please advise on whether it's appropriate to consolidate similar state variables in the above context

There is no definitive answer to this question, as different methods may have different advantages and disadvantages depending on the context and complexity of your application.

But I think this is a simple and straightforward way to implement sequential rendering, as you only need to update one state variable to switch between screens or steps.

const [screen, setScreen] = useState("page1");

return (
  <div>
    {screen === "page1" ? (
      <Component1 onNext={() => setScreen("page2")} />
    ) : screen === "page2" ? (
      <Component2 onNext={() => setScreen("page3")} />
    ) : screen === "page3" ? (
      <Component3 />
    ) : (
      "Page Not Found"
    )}
  </div>
);

The two approaches do exactly the same thing, the only difference is the number of useState hooks you are using<br> when a state update occurs in the parent component it will rerender and then check what to return based on state value.<br> having one or two states makes no difference.

> I am concerned this might lead to re-rendering of each component when screen is updated

it will only do for components within the returned JSX so if screen === 'page2' then only <Component2 /> will rerender

>Storing validation check and input values in an object to avoid having a state variable for each individual input

there are some alternatives as using refs for inputs you can do then validate before submitting or packages as Formik that can help you validate, but it is ok to make a state for inputs and if you want good performance you want to avoid rerendering the whole component so you can create a child component only for your form so it rerenders on its own

>Storing user data in useContext - updating one key updates the entire state and will likely trigger re-renders in multiple components

This will rerender only mounted components using the context and we want to do that to track user changes in each one of them that's great however if it is a case when you have multiple mounted components consuming the same context better to avoid that and just pass a state from the parent to each one of them, you see it depends on the case

There are two types of re-renders:

Necessary re-render

re-render of a component that is the source of the changes, or a component that directly uses the new information. For example, if a user types in an input field, the component that manages its state needs to update itself on every keystroke, i.e. re-render.

Unnecessary re-render

re-render of a component that is propagated through the app via different re-renders mechanisms due to either mistake or inefficient app architecture. For example, if a user types in an input field, and the entire page re-renders on every keystroke, the page has been re-rendered unnecessarily.

Unnecessary re-renders by themselves are not a problem: React is very fast and usually able to deal with them without users noticing anything.

However, if re-renders happen too often and/or on very heavy components, this could lead to user experience appearing “laggy”, visible delays on every interaction, or even the app becoming completely unresponsive.

so flow of re-renders is if a state variable changes it triggers re-renders in all the child components and the component itself but the whole app is not re-rendered. By this we can say that breaking up the application into optimal unit sizes can really help with this as re-rendering small components for small changes is way less load than re-rendering whole application or massive components. So it is important to make the application with this in mind.

I have found a article on the same, this should help:- https://www.developerway.com/posts/react-re-renders-guide