Clojurians Log v2

Hard to tell. I've personally never come upon a situation where being able to have some state to a component would have been the only way around. It's always possible to give a component state some identity, say a uuid, and store the required component state in the app state. On the other hand, some things a component might be occupied with are really transient in nature and don't belong in the app state either because: – no other parts of the app would ever be interested in that; – or on top of the previous item, the thing might be updated too often, which leads to lots of app state machinery being executed for no obvious benefit; – or the thing is some platform specific object (say, a JavaFX node instance not managed with cljfx) which I try to avoid storing at the context if possible.

What are cases where you think having local state might be beneficial?

> It's always possible to give a component state some identity, say a uuid, and store the required component state in the app state. I think local state will make it easier for the developer to develop using cljfx. I currently use UUIDs for local state in Reveal, and while it's a solution that works, it requires extra book-keeping and I always need to be aware that there is one big state with everything in it. It especially sucks in Reveal forms, which are stateful components with arbitrary nesting, so every component needs to keep track of local state of its children. With local state stored in the cljfx tree, there is no need to keep track of it.