Propsosal for an alternative approach to store setters

[JorrenH]

The current implementation of setStore is very convenient from a js DX point of view. Typescript however doesn't fare too well with the path based syntax which makes setStore so convenient. This impacts both maintainability of the store types as well as developer feedback, which can sometimes become a bit cryptic due to the type complexity.

Therefore I want to propose a new syntax for store setters which maintains the DX, while type complexity is greatly reduced.

Proposed syntax

The general idea is to move the path selectors from inside the store setter function to the outside. This makes it much easier to handle in typescript, as it only has to check one level of recursion at a time. A few examples:

const [store, setStore] = createStore<{
    a: number,
    b: number[],
    c: { d: number },
    readonly e: number,
}>({ .. });

setStore({ a: 1, c: { d: 2 }});        // merge syntax
setStore.a(1);                         // path syntax
setStore.b([ 1, 2 ]);
setStore.c.d(3);
setStore['a'](1);                      // dynamic path
setStore.a((prev) => prev + 1)         // with function
setStore.b[1](5);                      // set array index

The current approach to array modes is not compatible with this approach. I would propose the following for array typed store properties:

const [store, setStore] = createStore<{ 
    a: number[], 
    b: { c: number }[] 
}>({ .. });

const setNr: StoreSetter<number> = /*store setter*/;

// alternatives to `for`, setting multiple indices at once
setStore.a.for([0, 1, 2], setNr)
setStore.a.for([0, 1, 2])(setNr)
setStore.a.for(0, 1, 2)(setNr)

// alternatives to `filter`, setting items based on a predicate
setStore.a.filter((value, index) => true, setNr)
setStore.a.filter((value, index) => true)(setNr)

// alternatives to `range`, setting items within a range
setStore.a.range({ from: 0, to: 5, step: 2}, setNr)
setStore.a.range({ from: 0, to: 5, step: 2})(setNr)

// how continuation inside the array will work
setStore.b.for([0, 1, 2]).c(setNr)
setStore.b.for(0, 1, 2).c(setNr)
setStore.b.filter((value, index) => true).c(setNr)
setStore.b.range({ from: 0, to: 5, step: 2}).c(setNr)
setStore.b[3].c(setNr)

Discussion

I would like to see if others feel like this would improve store setters in a meaningful way. Of course there is a long way to go, but first experiments show me this syntax is possible to implement. I would like to first gather the general opinion before going ahead with an actual implementation of these ideas. For me there are the following considerations:

Pros:

• Type complexity for stores can be reduced by a lot
  • Improves IDE performance
  • Intellisense works better
  • Type errors are less cryptic
  • Easier to add new features w/o breaking type safety
• Functionally backwards compatible, migration is relatively simple

Cons:

• Syntactically not backwards compatible, users do need to migrate

Some other points of discussion:

• Does this syntax make sense to you?
• Do we expect an unacceptable performance impact with this approach?
• Array modes are made explicit, naming becomes important

[atk]

There are a few automatisms, i.e. multiple selections with automatically batched changes, that are impossible with this pattern. I'm sure there are ways around this, but I'm afraid they will be less convenient.

[JorrenH]

Are the automatisms some specific syntax which wouldn't be possible or 'under the hood' functionality of the stores? In the first case, could you provide an example of such syntax? For the second case I don't think there is anything in the current implementation which is impossible with this new syntax. Everything remains in scope of setStore, so any automatisms in there should still be possible.

As a proof of concept, I implemented a demo for this syntax. It is a proxy to the current setStore implementation so it has feature parity for all implemented syntax by definition. You can find the demo here https://stackblitz.com/edit/typescript-isyccq?file=playground.ts,wrapstore.ts.

[atk]

There are array, object and function selectors:

// Array selection of 0, 2 and 5:
setArray([0, 2, 5], 'done', true);
// Object selection of all odd numbers from 5:
setArray({ from: 5, by: 2 }, 'done', true);
// Function selection:
setArray((item) => item.done, undefined);

You could provide a replacement for array methods, but that wouldn't work for objects; the array and function selectors are really useful for those.

[JorrenH]

Ah, I understand what you meant now. These selectors are what for, filter and range are for. The examples you provide would map to the following in the proposed syntax:

// Array selection of 0, 2 and 5:
setArray.for([0, 2, 5]).done(true);
// Object selection of all odd numbers from 5:
setArray.range(({ from: 5, by: 2 }).done(true);
// Function selection:
setArray.filter((item) => item.done)(undefined);

It would be a bit more awkward for objects, but you could use the same 'for' syntax for them

// Object selection of 'a', 'b', 'c'
setObj.for(['a', 'b', 'c']).done(true);

This does mean you wouldn't be able to use 'for' as a store property, so that may be undesired.

[atk]

That would mean that you couldn't use for, range and filter as properties in your stores anymore. Not ideal. You could try to work around that using Symbols, but that makes it even more unwieldy.

[ryansolid]

Could also pick something that follows a convention and is unique enough and accept that there are collisions. I think for TS this is somewhat interesting. One thing I'm thinking more so is that the base implementation should be as minimal as possible and these sort of syntaxes should be layerable on top.

Where I'm sitting right now the simplest syntax to implement is a writeable proxy like what produce does. In fact if it shared a proxy under toggable modes it would have almost no code over reading values. It also works great with TS. This is the obvious choice. I want to keep path syntax around because I like it. But I'm thinking these sorts of syntaxes should be additive and opt in.

Only thing I see about chaining is the potential of people storing intermediate accesses. And trying to picture how that plays with batching. Chaining seems better when detached from the setter and a series of operations that can be applied. I don't talk about this much but I originally saw the paths as something storeable and then applied. Original syntax allowed arrays of arrays. I used it with something similar to Redux where I used reducers to create sets of path mutations to apply.