Simplify by combining van.state, vanX.reactive, and vanX.list?

[richcorbs]

Thank you for VanJS! I've been using it for two days now and am having a lot of fun. I come from the Vue/AlpineJS world and so this is a different paradigm for me and I'm liking it so far. For fun I'm building a simple CMS based on Google Sheets. I've built it already using AlpineJS + UnoCSS and when I learned about VanJS I thought it would be fun to also build it using VanJS. And I was right! It was fun!

One thing that was not as easy as the rest was the reactivity piece. Here is my use case:

• Side nav with list of clickable objects.
• Clicking on a side nav object selects that object for editing and populates the main section of the page with that object in an editor.
• Changing the object in the editor should update the object in the side nav.
• To get this working I had to use vanX.reactive and vanX.list.

My idea, and I don't know if this is even remotely possible, is to combine van.state, vanX.reactive, and vanX.list with the end result being that there is one way to declare reactive state and that the state automatically carries through to the DOM without having to use vanX.list. That would be amazingly simple DX!

I compare VanJS loosely with AlpineJS. AlpineJS is based on Vue's reactivity engine and there is only one way to declare state and it is reactive everywhere by default.

What do you think? Is this possible? Is it worth it to consider?

Thanks again for VanJS!

Rich

[Tao-VanJS]

Hi @richcorb,

Thanks for your interest in VanJS and thanks for your suggestion!

In short, I believe the DX that you desired will probably go against the simplicity and the no-dependency principle of VanJS. van.state (and perhaps van.derive) is the unified way of declaring states in VanJS. And vanX.reactive and vanX.list are extensions of VanJS to provide syntax sugar of complex state bindings. VanJS tries to distinguish itself for its simplicity, extremely small size, JSX-free, and zero-dependency. It doesn't attempt to mimic the DX of other frameworks.

Furthermore, since VanJS has passed the 1.0 milestone, any further evolution needs to be backward compatible, making it undesirable for more aggressive API changes.

Thanks again for your interest in VanJS!

[richcorbs]

Thank you for explaining this! I'm still learning VanJS.