3 ms·
> lots of UI state isn't handsome, core data Very true. My interpretation of the article was that it refers to "core data only". If you re-read the article as
by The_Amp_Walrus 7y ago
> lots of UI state isn't handsome, core data
Very true. My interpretation of the article was that it refers to "core data only". If you re-read the article as "How storing core data in a structure that is coupled to the UI increases accidental complexity" then I think you'll find it more agreeable.
Personally I throw stuff like popup state into local component state and the global important stuff into redux. Perhaps the author implicitly assumes that everybody does this.
- _bxg1 7y agoRight- like I said, local state is the natural solution in some cases. But it's not always so clean-cut. Maybe dropdowns were a bad example. Here's one I've run into: say you have a list of things that can be edited and then when you click "Save" it saves them all to the server. Each of those would need to track a "saving" state to drive its loading spinner. That saving state is transient and UI-specific, and it is tied to each instance of a list item in some sense, but it can't just be local to the list-item component because it needs to be a) set as part of global app logic, and b) read by, for example, the "save" button so it knows when you're allowed to click it again. There's an entire spectrum of these gray cases and there's no single answer for "how far up to hoist things". You're always making compromises. This is one reason I prefer MobX over Redux, because the latter basically locks you into "global state" and "local state" and doesn't allow for a lot of in-betweens.