SolidJS 2.0 one mental model for getters (Accessor vs Proxy)

[samuelstroschein]

Problem

1. Two patterns for reactivity exist in Solid. Understanding the difference needs explanation. A concept that needs explanation is not a good concept/ideally, no explanation is required.

signal() // <- accessor function
store.prop // <- store that leverages proxies to avoid a function call

2. Accessing a store with nested objects/props is a common pitfall.

store.nested // <- doesn't trigger reactivity
store.nested.prop // <- one must always listen to props/values

Proposal

Eliminate the two-concept getters by either making signals proxied objects or making store props accessor functions.

Given that stores are an addition to Solids reactive system, changing the store API seems to make more sense:

signal() 

store.nested // <- doesn't trigger reactivity, indicated by not using an accessor function `()`
store.nested.prop() // <- triggers reactivity, indicated by `()

Seems like the setters for store can be simplified with an API change too:

store.nested.prop() // <- reactive getter
store.nested.prop.set() // <- setter without the complex store settter API

Pros

• "everything is reactive that uses accessor functions". no more two concept split between signals and stores
• suddenly obvious why stores (props) can't be destructured. the accessor function would be lost.

Cons

• breaking change
• props with accessor functions might be odd.

[atk]

Feel free to contribute a community primitive that provides this API. Since stores are inside their own sub-package, they are only included if used. However, your concept could not be reactive for structural changes, e.g. exchanging two items in an array, since the branches are not supposed to be reactive. This would not be an issue for fixed-structure state, e.g. a server response, so this still might be a worthy addition, maybe even more in combination with valibot to define the structure.

We already have the static-store primitive that explored the possibility of having a one level deep object state, so another state primitive would fit into our scope.