Shared/global state and computed/derived state?

[mindplay-dk]

Hello,

Interesting little framework. 🙂👍

I was wondering about two features I don't see in this framework.

First, shared (or global) state: the ability to have state independent of component instances. I'm sure you've seen how people struggle with React, trying to cram everything into component state - before realizing they need a state management library of some sort.

Secondly, any plans to support computed (derived) state? In order to reap the real benefits of reactive state, we need to be able to both store and compute states - for example, how would you compute the number of TODO items in a list and display that?

Building a reactive state manager with shared and derived state might be a little more involved than you might think. 😊

[Tao-VanJS]

Since I am traveling I will make my answer brief. I will provide a detailed answer after I am back.

Global state is possible with code like this:

const globalState = {
  state1: van.state(...),
  state2: van.state(...),
  ...
}

Derived states are possible, see the implementation of the AutoComplete demo app: https://vanjs.org/demo#auto-complete

[mindplay-dk]

@efpage I gave DML a quick once-over, and I'm pretty sure this is opposite to the direction I'm looking - this is highly imperative, and I feel like I've already done every imperative approach known to man. 😅 ... I'm definitely looking to go more in the direction of declarative and reactive - I find this leads to much fewer bugs and less thinking about "what affects what" in a large application. I might have gone as far as to jump on Svelte, if not for the fact that I also really like the idea of leaning on the native platform - this is what gets me interested in approaches like that of Van. :-)

[Tao-VanJS]

Hi @mindplay-dk,

I would like to address your comments about derived states on 3 aspects:

1. API for derived states

I agree with you that the current VanJS API to define derived states feels manual. But in 1.0.0, I'm considering a more natural and ergonomic version, something like:

const candidates = van.derive(...)

This is pretty much the same as the corresponding API in Solid and Maverick.

2. State persistence

I think any framework with derived states support needs some sort of persistence, cuz the point of derived states is to avoid duplicate computation. Otherwise we wouldn't need derived states, just defining functions would be enough. I think the real difference between VanJS and the frameworks you mentioned is actually the 3rd aspect: eager vs. lazy evaluation.

3. Eager vs. lazy evaluation

Right now my current belief is that eager evaluation (the "push" model as you mentioned) is a better implementation for most use cases. Lazy evaluation is indeed easy to add with some thin wrappers, but I would like to know if there are mainstream use cases where lazy evaluation is significantly more beneficial before making the call to include it in VanJS.

[mindplay-dk]

I think any framework with derived states support needs some sort of persistence, cuz the point of derived states is to avoid duplicate computation.

Yes, you are correct. Not sure what I was thinking there. :-)

Right now my current belief is that eager evaluation (the "push" model as you mentioned) is a better implementation for most use cases.

So, let's suppose you have a form with a radio group with 10 options - each of those switch between various computations. Some of those might be expensive - if even one of them is expensive, you're going to have this overhead regardless of the current selection.

And this might be a somewhat separate issue, but also, generally these abstraction support laziness as well as asynchrony - if one of those mentioned options requires you to fetch some data, no worries, this data won't be fetch until you select that option; possibly never.

Lazy evaluation just means you don't have to worry about things like that. It basically is just like punching values into a spreadsheet - anyone can do it, everything is implicitly cached, automatically disposed, computed or fetched as needed.

You can focus on your application requirements, and let the code be expressive and declarative, without and distractions.

The main issue, as mentioned, is these models generally aren't simple - it's very difficult to get this right. Libraries such as Maverick or Oby are really well designed, highly optimized, and tested to support these requirements, and they're both impressively small for all the complexity they handle. I doubt it's possible to do it much better in terms of performance and file size. Given how small and carefully optimized these libraries are, personally, I wouldn't hesitate to just pick one and try it out. 😊

[efpage]

Please keep us informed about the result. Being able to use 3d-party state management with VanJS would be a strong point.

[Tao-VanJS]

Thanks @mindplay-dk for your detailed comments. I would like to express my opinion on this issue.

Personally I don't think lazy evaluation is a good solution for the use case you described. Let's take the scenario of heavy computation as an example. Usually there are more things we want to control than just delegating the evaluation to the framework. Do we want the computation done in the main thread, or done in a background worker? When do we want to start the computation? Upon user clicks the radio button (which will freeze the web page), upon the page loading, or when idle? Async evaluation faces similar choices: do we want to fetch upon user clicks the radio button, or do we want to prefetch? Furthermore, async evaluation has some additional problem to deal with: how to render the UI when data is being fetched?

One of the design philosophy of VanJS is to stay close to vanilla JavaScript as much as possible. Thus the abstraction like this which restricts the way how the developers would do in vanilla JavaScript to optimize the user experience is not something I want to include. Indeed, I think the best solution is to ensure the UI always consistent with the underlying states, synchronously, where a "push" model is preferred.

Also, it's not a bad idea to model async fetch in this way:

const data = van.state({status: "unfetched"})

const fetchData = async () => {
  data.val = {status: "fetching"}
  const result = await fetch(...)
  data.val = {status: "fetched", result}
}

This way it would be quite straightforward to map data to the UI.

[Tao-VanJS]

Hi @mindplay-dk,

VanJS 1.0.0 was just released today. We finally have a unified API van.derive to define derived states. See section Derived states in the tutorial for more details. Hope this can satisfy your need :-)