For me React is about seeing "component", as opposed to seeing "global". For me React is component-based programming
That includes: state management and styling. I'd avoid anything global as much as possible, and make a component independent (non-sharing) as much as possible.
(Forget folder hierarchies. Stick to a single level of folders as much as possible, such as: components, hooks, pages. The modern IDE's will find the file for you. I think folder trees cause duplication and redundancy.)
The main reason for doing state management and styling globally is to allow reuse and easier modification in one place.
If you don't do state managment, you still need to communicate state between components, which don't make them independent but coupled. And seperating the logic to handle state and backend calls from components makes the logic independent to use by various components.
Folder hierarchies makes better readibility, but it's really a good pratice where it doesn't impact performance so it's your choice to use it or not.
Yes, fully agree :) Styles and states IMHO should stay as close to the component that needs it as possible, as long as possible.
It reduces the number of rerenders + it is easier to flexibly reuse components.
If you start coupling components with a global state/store sooner or later you won't be able to reuse it in any part of the app that does not use the same global store. And then decoupling it might be a nightmare.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'll respectfully disagree
:o).For me React is about seeing "component", as opposed to seeing "global". For me React is component-based programming
That includes: state management and styling. I'd avoid anything global as much as possible, and make a component independent (non-sharing) as much as possible.
(Forget folder hierarchies. Stick to a single level of folders as much as possible, such as: components, hooks, pages. The modern IDE's will find the file for you. I think folder trees cause duplication and redundancy.)
The main reason for doing state management and styling globally is to allow reuse and easier modification in one place.
If you don't do state managment, you still need to communicate state between components, which don't make them independent but coupled. And seperating the logic to handle state and backend calls from components makes the logic independent to use by various components.
Folder hierarchies makes better readibility, but it's really a good pratice where it doesn't impact performance so it's your choice to use it or not.
Yes, fully agree :) Styles and states IMHO should stay as close to the component that needs it as possible, as long as possible.
It reduces the number of rerenders + it is easier to flexibly reuse components.
If you start coupling components with a global state/store sooner or later you won't be able to reuse it in any part of the app that does not use the same global store. And then decoupling it might be a nightmare.