21–30 of 51 posts
Controller. You need a controller. Or a smart model, in this simple case. That’s what react/redux has done to you, selling this ‘immutable functional’ flavoured thing. While it is immutable at the programming surface, it is actually a series of complex updates with little to no help from the ‘store’ for convenient access. In pure js, when you want project.tasks, you just: class Project { get tasks() { return db.tasks…
That second "model" is insane... is that actually something people do?
Earlier quoted context omitted.
Shouldn’t the panel’s width be stored on the Panel component, and all items in it should probably just be width 100%, or styled to fit the Panel via CSS. That’s the last bit of UI state that I’d ever think to move up to the global store. The dropdown would act in the same way, no? It mostly sets some local state, and your can then derive the data you need from the store (let’s say the drop down was just an on/off fil…
Specifically for dropdowns, you usually want to keep their open / closed position in the UI state explicitly, because you want to close an open dropdown when the user clicks on another dropdown. I frankly think that this complexity is not accidental. It is the real complexity of the UI, which is often not realized. All the little things that need thought and, at least once, an implementation.
Controller. You need a controller. Or a smart model, in this simple case. That’s what react/redux has done to you, selling this ‘immutable functional’ flavoured thing. While it is immutable at the programming surface, it is actually a series of complex updates with little to no help from the ‘store’ for convenient access. In pure js, when you want project.tasks, you just: class Project { get tasks() { return db.tasks…
Isn't this what selectors are for?
Earlier quoted context omitted.
So my initial feeling is that it almost seems like you are reimplementing base React. Isn’t this effectively prop drilling, with a bunch of child components lifting state up to the global parent component (so that they all get updates?). Apologies if I’m simplifying it.
Well I'm using React so I can't be re-implementing it :) I'm not advocating for any ground breaking paradigms here, I guess my only point is that the common advice to just throw everything into Redux (global store) is bad advice. You should only put global state into your global store. The common alternative is to silo state and functionality/UI into one component. I'd argue the third alternative, taking the best of…
The proposed approach is correct for the proposed use-case. The problem is, lots of UI state isn't handsome, core data like in this example. What about storing the width of a resizable panel? Or the state of a dropdown that can be open or closed? Do you create a dozen little flags in your store for these? Or do you put a flag on each domain object (todo list item, for example) that's not actually relevant to your bus…
The way I handle this, at least in React, is to create a context provider that handles my component's view state, then write my UI element as a consumer of that view state by wrapping it in an HOC. Then, if any other component wants to subscribe to the particular user interaction that drives the component I'm writing, they can simply tap into the existing context with an HOC that I've already written for them. This w…
Being able to change data schema with little overhead allows to operate on a less normalized structure and adjust it more frequently. Meanwhile, designing a highly normalized schema and implementing complicated queries takes time and still doesn’t make it entirely proof against the future.
Nitpick: UI-agnostic data schema example is what conventionally is referred to as normalized—closer to a theoretical canonical form, independent of query convenience at runtime. The other example, where tasks are child nodes of a project, would be the denormalized one.
(I'm not saying the above would be better than what we have, just that it seems like it should be properly explored)