Reactive/Store-like primitive

[marvinhagemeister]

// Turns properties into signals
const r = reactive({ foo: 123, bar: "hehe" });

console.log(r.foo.value);

Open question: Should conversion be deep or shallow?

Pros

• Easy to make an existing object reactive

Cons

• tbd

Update with assign()-syntax

// Update a Reactive with assign()-like syntax:
const r = reactive({ name: "Alice" });
update(r, { name: "Bob" });

// property 'age' does not exist in type '{ name?: string }'
update(r, { age: 42 });

// '2' has no properties in common with '{ name?: string }'
update(r, 2);

console.log(r.name.value); // "Bob"

Pros

• Good for Redux users?

Cons

• Ambiguity for collections/arrays: Should we update or concat?
• Is this needed for an MVP or could this be added in users themselves? What's the use case?
• Risks forking update logic

[marvinhagemeister]

FYI: Devtools doesn't use something like that.

[JoviDeCroock]

I think we should deeply wrap items so that we can for instance do

const r = reactive({ count: 0 });
r.count.value++

and see stuff change, not entirely sure if it's possible but those are my two cents coming from the Vue-like syntax.

[marvinhagemeister]

@JoviDeCroock That's a great idea! I think it'd definitely be nice to have some sort of helper method that initializes object properties as Signals. I'm not sure how deep that should go. Do you know how Vue handles these cases?

// Are both "foo" and "bar" signals now?
const r = reactive({ foo: { bar: 123 }});

// Are both "foo" and the inner elements in the array signals?
const r = reactive({ foo: [ { bar: 123 }, { bar: 444 } ]});

[JoviDeCroock]

The reactive conversion is "deep": it affects all nested properties. A reactive object also deeply unwraps any properties that are refs while maintaining reactivity.

From the explanation I assume it would wrap all of them as individual signals, it's hard to tell in the CSB as they eagerly unwrap https://codesandbox.io/s/magical-swanson-3cpwb8?file=/src/App.vue

[marvinhagemeister]

Currently looking at valtio and the more I look at it, the more I like it. Originally, I was worried that having two kind of values (proxy + boxed .value) primitives would be confusing, but I see myself moving away from that stance. Looking at devtools the proxy approach would help me reduce typing noise quite a bit. There, I've typed everything as explicitly being an observable, but with proxies all that could be dropped.

[fabiospampinato]

Quick and dirty, but I repurposed the port of $.store from Oby that I did for Solid for Preact/Signals: https://codesandbox.io/s/sparkling-cherry-bn9bu5?file=/src/index.js

It doesn't seem entirely broken, but there seem to be a bunch of APIs missing that would be needed to implement this efficiently.

[EthanStandel]

I came here to recommend this and for anyone in the mean-time, I just published a package called preact-signal-store which is meant to do just this. I expose a deepSignal which takes an object and makes every atomic property a Signal and makes every parenting object a DeepSignal type. The DeepSignal type has peek and a value getter and setter that act just like Signal but it strictly reads from and writes to the underlying Signal properties lower in the tree.

I personally think this model would make sense in @preact/signals but I'm curious what maintainers and the community think

[chenjiangui]

deepSingnal is helpfull

[chenjiangui]

I think we should deeply wrap items so that we can for instance do

const r = reactive({ count: 0 });
r.count.value++

and see stuff change, not entirely sure if it's possible but those are my two cents coming from the Vue-like syntax.

r.value.count++

is better, if you have three or four deep object

[EthanStandel]

r.value.count++

is better, if you have three or four deep object

@chenjiangui I feel like that's kind of more confusing. One of the rules of a Signal in @preact/signals is that it's always the .value that's writable, and in the value setter there is the code to fire off the updates to the listeners. But I think that if r.value gave you a set of properties that were writable & listenable, it would kind of go against the model that's set and would really blur the line between what is listenable and where the actual state is, because r.value.count++ isn't reassigning r.value, it's reassigning r.value.count.

In preact-signal-store, I set up deepSignal such that you can't do this (in TS at least, I didn't feel like it was worth the overhead to actually freeze the objects at run time) so there's no lack of clarity.

import { deepSignal } from "preact-signal-store";

const userStore = deepSignal({
  name: {
    first: "Thor",
    last: "Odinson"
  },
  email: "thor@avengers.org"
});

// TS error: Cannot assign to 'email' because it is a read-only property.
userStore.value.email = "another@email.com";

Notably, what would work is this, which would actually update the original email Signal for all listeners.

userStore.value = { email: "another@email.com" };

[eddyw]

I opened a PR #217 PoC which could allow a single signal to track multiple values rather than creating multiple signals per each property.

The PR doesn't attempt to be the "Reactive/Store-like primitive" but rather a building block which could allow to do it.