Hacker News Reader

Comment by brulard | Hacker News Reader

I believe having application state defined independently of the UI components is very helpful in separating concerns. I can debug the state of the application as data only, without needing to dive in to the UI components hierarchy. UI is just a representation of that state and there can be more than one such representation. Singleton isn't bad if it is used only for reading the data. Mutable global state is the problem.

View on HN

I think you are essentially talking about unit testing your stores, and in the case where there might be a lot of logic inside them, is a good idea in principal.

But take the case of an app using local state, this logic if indeed separable from UI, could be coded as functions, rather than within imperative object 'stores'. And these functions would obviously be just as testable.

You mention redux in your original comment and I wouldn't call redux store an imperative object. You have pure functions (reducers) updating a state, which is just a simple object without methods. The benefits I see in using this one application state is that I can easily debug the state of the application, I can easily serialize the whole state and include it in a crash report and the devtools for redux are very helpful. Although YMMV

> Singleton isn't bad if it is used only for reading the data. Mutable global state is the problem.

If it’s read-only, you can just declare it as a constant. No need to add a state management library.

Read-only != constant. State management library can provide you with globally readable state represented by stream of immutable values.

Reply on news.ycombinator.com