RFS: Store refs

[mstijak]

This is a new proposal for store refs following #482 and #347.

Store refs would reduce the number of string bindings and optionally add typing.

let enabled = store.ref("enabled");
enabled.toggle();
enabled.set(true);

The second argument could be the initial value.

let enabled = store.ref("enabled", true);

Typed store refs would allow easier array or tree operations.

let records = store.ref("records").as(ArrayRef)
let first = records.get()[0];
records .set([]);
records .append({ id: 1 });

For trees, it would be slightly more complicated as it's required to know the childrenField.

let tree = store.ref("test").model({ type: TreeRef, childrenField: "$children "});
tree.findNode(n => n.id =="x");
tree.removeNodes(n => n.id == "x");
tree.findNodeRef(n => n.id =="x").append(newNodE);
tree.findNodeRef(n => n.id =="x").removeNodes(newNodE);

Store refs would work nicely with functional controllers.

export default ({ref}) => {
  let tree = ref("tree");
  return {
    onDelete(e, {store}) {
       let id = store.get("$record.id");
       tree.removeNodes(n => n.id == id);
    }

    onAdd(e) {
       tree.append({ text: 'New node' });
     }
  }
}

It might be possible to make functional components to work with store refs too. However, that would require that widgets support getting data from external stores.

const Field = ({ store, prop1, prop2 }) => {
  let array = store.ref("$page.records").as(ArrayRef);
  return <cx>
    <Rescope bind="$page">
      <Grid records={array} visible-bind="on" />
      <Button onClick={(e, {store: recordStore}) => { array.append({ })}} />
    </Rescope>
  </cx>

This change might introduce problems as developers might be tempted to create new stores on the fly.

const Field = ({ }) => {  
  const store = new Store();
  return <cx>
    <div store={store}
      <TextField value-bind="x" />
    </div>
  </cx>

In this case, the top-level store would never get notified and the UI would not re-render on changes originating in the component. Does the simplicity outweights the danger?

[sasatatar]

Perhaps getters and setters should be polymorphic, that is, support getting and setting specific properties within the store reference. Consider the example:

export default createFunctionalComponent(({
    store, 
    // user binding
    user
}) => { 
    let userRef = store.ref(user.bind);

    // get entire user object:
    let val = user.get();

    // get user language:
    let language = user.get("language"); // the same as: user.get()["langauge"];

    // set language:
    user.set("language", "en"); // the same as: user.update(u => ({ ...u, langauge: "en" }));

    // setter should behave as `update` if a function is provided:
    user.set(u => ({ ...user, language: "en" }));
    
    ...
});

[mstijak]

It's easy get a reference for a nested object:

let language = store.ref("user.language");

What you're describing would be like a store rescope feature.

let userView = store.zoom('user');
userView.set('language', "en");

This might be a new feature of stores. I wouldn't mix that with refs. Definitely an interesting idea.

[sasatatar]

Exactly. That would solve a bunch of problems due to hardcoding some store paths in multiple files.

It would also be great if we could use store refs to add/remove triggers. Something like this:

let userRef = store.ref("user");
userRef.addTrigger("onUserChange", (user, {store}) => ....);

[alimorina]

Hi @mstijak can you help me if the store refs are included in the current version of cx I have installed:

    "cx": "^20.4.5",
    "cx-react": "^17.10.0",
    "babel-preset-cx-env": "^18.5.0",
    "babel-preset-env": "^1.7.0"

Thanks in advance.

[mstijak]

I think they are.

https://unpkg.com/cx@20.4.5/dist/data.js