Exactly, state management is a job for the app itself not the components it's built from. You don't expect a form field to manage it's own state beyond the specific features that it provides. You wrap extra logic around it to suit your specific use case then you wrap an app around that. Simple separation of concerns.
React is a state management library that happens to be able to supply dom elements (with react dom) I think you're more fight against bad react usage rather than react as a whole.
Actually, I would argue against any bad usage of web technologies regardless of the library or framework involved. The core Web APIs provide a finely-tuned, meticulously-documented, consensus-based framework without the need for any additional libraries.
Browsers are perfectly capable of maintaining state through Session Storage, Local Storage, IndexedDB, cookies, bfcache, and service workers (anything I missed?) each with their own specific use cases. And because of the open nature of the web you can NEVER trust the client anyway, so the one and only true state should be that held by the server itself. With Web Sockets this can be synced in real time to the client. I don't see why a third-party state management solution would ever be necessary.
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.
Exactly, state management is a job for the app itself not the components it's built from. You don't expect a form field to manage it's own state beyond the specific features that it provides. You wrap extra logic around it to suit your specific use case then you wrap an app around that. Simple separation of concerns.
React is a state management library that happens to be able to supply dom elements (with react dom) I think you're more fight against bad react usage rather than react as a whole.
Actually, I would argue against any bad usage of web technologies regardless of the library or framework involved. The core Web APIs provide a finely-tuned, meticulously-documented, consensus-based framework without the need for any additional libraries.
Browsers are perfectly capable of maintaining state through Session Storage, Local Storage, IndexedDB, cookies, bfcache, and service workers (anything I missed?) each with their own specific use cases. And because of the open nature of the web you can NEVER trust the client anyway, so the one and only true state should be that held by the server itself. With Web Sockets this can be synced in real time to the client. I don't see why a third-party state management solution would ever be necessary.