Write test for your components, you never know who is the next one to work on it. A Written test for a component, is the documentations for your work.

If you are dealing with data passing then always handle the case where data might be empty (by using ? Operator), so that your app doesn’t crash at least.

Always think twice where data needs to be initialised. At parent level or at the component level or is it needs to be global.

Always think for near-future changes. Is your component is going to be used at multiple places. Then how difficult it will be for future collaborators to make that change. If your component-level states are going to get bigger, then how easy it will be for another dev to add that state and move on.

Not everything needs to be re-usable from day zero. You should only write a re-usable component when it falls in your architecture plan or the requirement for the component to be common is crystal clear. Re-usable components can be super complicated very easily. So thinking of every component as a common one introduces unnecessary complexity into codebase.

10 out 10 times write local level or component level CSS. Use module or tailwind or CSS-in-JS stuff, whatever suits you. But if you are planning to use just normal css with manually written classnames everywhere, a nightmare is waiting for you.

Try to have your own mini patterns when the code base is a bit bad and doesn’t come with any pattern. This will be your chance to write good code in a not so well maintained codebase. But remember to be consistent with the patterns.

Data flow in a react codebase is like the queen of chessboard. If you loose control over it, then you will eventually lose the game. So whenever, the product design changes in a good amount, please re-think how you have written the data flow.