Focus on Maintainability
The best feature of modern frameworks is the component which you can reuse at multiple places. But if that same component is given multiple responsibilities to handle, then you are misusing the component. A component should be designed with one feature in mind. Bypassing multiple props to the component and using if-else conditions in the component to render different layouts is a bad idea. Ideally, you are trying to save development hours in the beginning but as time passes that same component will start accommodating more and more features and very soon it will become a huge component.
Now let some months pass, and you come back to modify the component either due to a bug or to add a new feature. Even though the code was written by you, it will take some time to understand what you had written long back. Assuming your memory is good and you remember everything vividly, you start injecting additional code and test the functionality. But the time it took you to add new code would be longer this time and there are high chances that you might introduce new bugs. The reason? This same component is used at multiple places and you might have forgotten to verify all the scenarios.
For example, if you are supposed to create a responsive site, and you need your header to look different on different devices, then it’s better to create two separate components.
It is believed that if you don’t focus on maintainability from the beginning, your maintenance cost will be higher than the development.
Props Drilling is NOT bad
I have often seen people getting angry with what is called props drilling when they have a long hierarchy of components communication. And to prevent this they fall back on state management solutions like Redux or Akita. Well, such solutions are very good to handle communication where there is no parent-child relationship. But when you start using them in the parent-child hierarchy you are making your components less reusable. Based on my experience, it is always good to go with props drilling if you have a three-level hierarchy. If you have more, then opt for Context API.
If you have an enterprise application that has multiple portals then monorepo is for you. It offers you high reusability with better code management. Rather than creating multiple repositories, create small independent projects/modules into one big repository. Through this way, you can extract common components like Auth (login/logout/forgot password), UI library, etc into a shared module. All modules will have their own package.json file, so it will be very easy to manage dependencies. One such framework you can use is Nrwl.