VanJS state concept

[efpage]

I read a lot about state management and THIS post made me think about the role of state management in an app:

functionality produces state — not the other way around.

Van.states are conceptually working very close to the DOM. Updating a state object immediately updates the bound DOM elements and event listeners. This is convenient in many cases, but my question is:: Is it enough?

As discribed in the post referenced above, a view is always the result of the current state of an application, and this is influenced by functional logic implemented in the app. But a VIEW is only one aspect, and usually not the most important one. Even further, the application logic should also work without the VIEW.

So, the question is: what role should the VanJS-state play in an app? For a full featured state management, it is possibly missing too many features. If we use any third-party-solution, can this benefit from Van.state?

[Tao-VanJS]

Since I am traveling I will provide a brief answer:

van.state is a convenient mechanism in such a way that, when used properly, application code can only deal with states, without the need of directly dealing with the DOM tree. It positions itself as a tool to help people write maintainable code.

That being said, VanJS doesn't want to force its users to always generate DOM tree based on states. VanJS supports multiple paradigms, and is unopinated on any paradigm. I understand sometimes it's desirable to manipulate DOM tree directly, for performance or for convenience.

Speaking out of the context of FE programing, despite the well-known benefits of functional programming, very few people are advocating doing everything in pure functional programming. People naturally understand when is appropriate to do functional programming and when is appropriate to do procedural programming. With regard to FE programing, I believe it's possible to have a UI framework that allows direct DOM manipulation.

[efpage]

Dear Tao,

thank you for your explanation.

So, as the DOM is stateful, there is no real difference between working on states or working on the DOM directly, right?

What are the advantages of using Van states

• We will get some benefit, if multiple DOM elements are bound to one state, as Van-states can act as a dispatcher.
• States can be initialized during creation

Whishlist

I understand, that VanJS should be as lightweight as possible. But possibly there could be some kind of "extensibility" to let users add new functionality to the state system? Like an onStateCreate-event?

• I could see a lot of benefit, if state propagation could be delayed or synchronized within VanJS. This could give a better user experience. Assume you need to fetch some data during DOM update. This usually is too slow, so the browser will display an empty containter, wait until fetch is finished and then show the final result. It would be convenient to delay state propagation intentionally until the data are present. This is also helpful to supress the display of unwanted intermediate states.
• Implementation of a persistance mechanism (like store and reload of states)
• Implementation of new events for state handling. There could be events depending on the display state of a component, onBeforeRemove etc...

[Tao-VanJS]

Yes. States are meant to provide a good abstraction of the status of the UI. They can be handy if the abstraction is proper. But sometimes directly manipulating DOM tree is more convenient, as you can see in many examples of VanJS demo page.

I think a lot of features in your wishlist are already possible in the current version of VanJS. In 1.0.0 release we're going to overhaul the API of state derivation and side effects. After 1.0.0 release I will comment this thread about how different kinds of advanced state handlings can be achieved via VanJS API with very simple code.

[Tao-VanJS]

I think with 1.0.0 release, a big portion of your wishlist can be achieved with van.derive API. You can refer to section Advanced state derivation for sample code.