Reactive state/derive with van-plate?

[btakita]

Hi, is reactivity with van-plate under consideration? I would like to utilize reactivity on the server. I could extract the reactivity from vanjs-core but was wondering if anyone else has the need for reactivity using with SSR/nodejs/bunjs/deno processes...

That being said, the biggest draw is a small browser payload (vanjs-core). If I have to duplicate the reactive logic to support isomorphic components, that duplicate code would make the browser payload a bit larger. Saving a few hundred byes on the server side is not much of a concern, IMO...but it seems like SSR reactivity is not a common use case.

I don't have a need to make the generated html reactive. I use reactive state/derive values in some logic.

[Tao-VanJS]

I'm not aware of any use cases where reactivity on the server side is super helpful. If you have some concrete use cases, I'm happy to learn.

[btakita]

Hi @Tao-VanJS,

I ended up creating https://github.com/ctx-core/vanjs which includes reactive state & derive without a DOM...Using WeakRef for GC purposes.

With a ctx, reactivity allows state to be composed into. I should give a bit more detail about how I do it. I worked @ctx-core since 2016 with a general strategy of using a Ctx with dependency injection. The Ctx has evolved from an object (as most do it), to a Map or a nested array of Map.

From https://github.com/ctx-core/object/blob/master/src/be_/index.d.ts:

export declare type MapCtx = Map<Be<unknown>|string|symbol, unknown>
export interface NestedMapCtx extends Array<NestedMapCtx|MapCtx> {
}
export type Ctx = MapCtx|NestedMapCtx
export declare type Be<
	Val,
	ctx_T extends Ctx = Ctx
> = ((ctx:ctx_T, params?:be_params_T)=>Val)&{ id?:string }

A Be (or "being"), is instantiated with the be_ function.

import { type nullish, nullish__none_ } from '@ctx-core/function'
import { be_derive_pair__new, be_state_triple__new, reactive_derive__new, reactive_state__new } from '@ctx-core/vanjs'
import type { State } from 'van-type-delegate'
export interface Person {
	name:string
}
let [
	param__person_id$_,
	param__person_id_,
	param__person_id__set,
] = be_state_triple__new('param__person_id', ctx=>reactive_state__new(ctx, null))
let [
	person$_,
	person_,
] = be_derive_pair__new('person', ctx=>{
	let person_state$ = reactive_state__new<Person|nullish>(ctx, null)
	let person$:State<Person|nullish>&{ _ref?:{} } = reactive_derive__new(ctx, ()=>person_state$.val)
	person$._ref = { // reference to avoid GC (reactive_derive__new uses WeakRef)
		person_fetch$: reactive_derive__new(ctx, async ()=>
			nullish__none_([param__person_id_(ctx)], async param__person_id=>{
				// Staleness check left out of this example
				try {
					let response = await fetch(`https://localhost/people/${param__person_id}`)
					person_state$.val = await response.json()
				} catch (err) {
					console.error(`person|catch`, { err })
					person_state$.val = null
				}
			}, nullish=>person_state$.val = nullish))
	}
	return person$
})
let [
	person__name$_,
	person__name_,
] = be_derive_pair__new('first_name', ctx=>
	reactive_derive__new(ctx, ()=>person_(ctx)?.name))

This is more complicated than merely calling fetch inline...so why do this? Each bit of state can be defined into a discrete chunk only with references to direct dependencies. Second level+ dependencies are abstracted into the ancestors. This pattern allows most dependency injection to only require the ctx. So with increased complexity in defining the state, complexity in setting up the state graph & calling the state is reduced.

This is beneficial when working with complex domain logic. Rather than directly injecting all of the dependencies in the call graph, a graph of "beings" are defined. This allows the state dependency graph to be reused in flexible ways. A Be is lazy-loaded, so if it's not used, it's function is not called. Also, a ctx holds an instance of the state dependency graph, so it supports concurrency. Since a Ctx = MapCtx|NestedMapCtx, it can also read from multiple MapCtx (e.g. including process level graphs as well as entity graphs). The "source" MapCtx can be defined with is_source_ in be_params...allowing the programmer to select what MapCtx a Be will be instantiated on.

Another benefit is reactive domain logic can be isomorphic. In the case of isomorphic VanJS, I only need to pass in a ctx into the component for all context state. This includes the van object as well as other all other domain context state. This is also useful for "Island Architectures" or multiple rendering mechanisms, such as in astro.

A reactive library adds reactivity to the Be graph. I have already been using nanostores, svelte stores, & solidjs signals for years now...recently adding VanJS reactive stores.

Nanostores is going through a major version update to add it's own contexts, with server side reactive state as a primary use case. I can already use nanostores on the server side with ctx-core.

I hope this makes sense. Please let me know if you want me to go more into specifics. ctx-core has had significant churn for years but it's api is relatively stable for over a year now. I've held off documenting it until it reached stability, so I will do so soon.

[Tao-VanJS]

Thanks @btakita for sharing the context!

My general feeling is that the use case might be too specific for reactivity to be added into van-plate.

Another benefit is reactive domain logic can be isomorphic. In the case of isomorphic VanJS, I only need to pass in a ctx into the component for all context state. This includes the van object as well as other all other domain context state. This is also useful for "Island Architectures" or multiple rendering mechanisms, such as in astro.

For the van object of van-plate, you can create State objects, use binding functions, etc. Thus components can work in van-plate environment if they merely use States and binding functions. The thing that is currently not supported in van-plate is that the rendered components are not reactive to state changes. But I feel that for SSR components, the use cases for them to be reactive to server-side events are quite sparse.

[btakita]

I agree that it is currently a rare occurrence...but I think it's because it's not really an available option to use with the major libraries...except RxJS or perhaps some React-related library? A context independent of the component tree/DOM is necessary for asynchronous concurrency-safe domain logic. You can kindof do it with SolidJS Signals, but a <Root> is needed & SolidJS has synchronous rendering. createResource is an option but that requires <Suspense>, which I have found difficult to use. <Suspense> doesn't seem compatible with Astro. SolidJS 2.0 is going to make the Signals independent of the component tree. Both Svelte & Solid need some extra mechanism (like @ctx-core) to make the Stores/Signals async concurrency-safe...meaning supporting async functions with concurrent requests.

At least in nanostores, there is a desire to & work toward supporting reactive in-process domain logic. The use case seems mainly around isomorphism...re-using reactive domain logic on the browser/server vs having to maintain, in parallel, duplicate imperative (server side) & reactive (browser side) domain logic. Just as an example, I have thousands of WritableAtom & ReadableAtom objects in a couple of projects, which can be used on the browser or server. The flexibility to choose one or the other or both without needing to retool the domain logic is quite nice, especially for complex projects.

In my experience, there are further benefits, but they won't be "discovered" until more people regularly use reactive state on the server side or process side. I also use reactivity for import processes & even devops.

That being said, if someone reading this is looking for server side or in process reactivity...@ctx-core/vanjs does have reactive state/derive, if one is willing to use @ctx-core. If not, the implementation is simple & a new library can be created.