SolidJS•2w ago

Does store setState check for equality before updating signals?

Does it make sense to manually check if a value is actually different before running setState/setStore? I mean, are reactions run even if the value is the same as it was before? If not, does it make sense to make like a helper function, which wraps setState in an if block, and only runs it if it's actually needed? Of course it wouldn't work on functions, etc. passed in, but I'm talking about basic cases, like setting strings or arrays of strings.

35 Replies

peerreynders•2w ago

like setting strings or arrays of strings.

The issue with arrays it that [] !== [], i.e. if you replace one array with another one that contains the exact same strings—the arrays are referentially different, so change propagation will still occur.

hyperknotOP•2w ago

but I mean, I can check it in my own function and only run the setState if they are different or use some deep equal utility lib, like lodash's isEqual: https://lodash.com/docs/4.17.15#isEqual

peerreynders•2w ago

In the general case just structure your store with an easily identifiable key and use reconcile to update it.

reconcile - SolidDocs

Documentation for SolidJS, the signals-powered UI framework

hyperknotOP•2w ago

but does reconcile work with a single string as well? I mean I want something like setState('selected', 'abc'), will it avoid the trigger if this.state.selected === 'abc'? So this is the first line of store.ts / setProperty:

  if (!deleting && state[property] === value) return;

  if (!deleting && state[property] === value) return;

In my understanding it means that even without using reconcile, for simple values like strings, it will NOT trigger a signal. Can you help me confirm this? For example, how can I log what these functions would trigger?

const [state, setState] = createStore({ selected: 'initial' });
setState('selected', 'abc'); // First call
setState('selected', 'abc'); // Second call (same value)

const [state, setState] = createStore({ selected: 'initial' });
setState('selected', 'abc'); // First call
setState('selected', 'abc'); // Second call (same value)

peerreynders•2w ago

https://playground.solidjs.com/anonymous/538e808a-490e-43a3-93c3-6f5ac26d69c3

Solid Playground

Quickly discover what the solid compiler will generate from your JSX template

peerreynders•2w ago

As you can see neither

setStore('selected', 'abc');

setStore('selected', 'abc');

setStore('selected', reconcile('abc'));

setStore('selected', reconcile('abc'));

trigger the effect.

hyperknotOP•2w ago

I see, great to know! Thank you for the snippet. So as a general rule, I don't need to use reconcile for simple types but need reconcile for complex types.

peerreynders•2w ago

In JavaScript terms objects are non-primitive and arrays are objects. Solid handles equality of non-primitives with reference equality rather than value equality.

hyperknotOP•2w ago

I understand. I just don't see why would I ever not use reconcile? I mean I can even imagine the idea to simply put it inside setState and always call it.

peerreynders•2w ago

For pinpoint updates it is unnecessary overhead. Also the path syntax is a lot more flexible than that. As Joe Armstrong (co-creator of Erlang) once said “primitives from which mechanisms can be built”. Solid core is about the primitives you need to build the mechanisms that fit your exact use case.

Kent Computing

YouTube

Erlang Master Class 2: Video 2 - Abstracting patterns of concurrency

http://www.cs.kent.ac.uk/ErlangMasterClasses These Master Classes will show you how Erlang can be used in practice to solve larger problems. The examples provide 'capstones' for different aspects of Erlang: functional programming, concurrent programming and larger-scale programming with OTP. Erlang is best known for its “share nothing” concurr...

Stores - SolidDocs

Documentation for SolidJS, the signals-powered UI framework

peerreynders•2w ago

Also there is some behaviour that may surprise you

function App() {
  const [store, setStore] = createStore({ selected: ['abc', 'def'] });

  createEffect(
    on(
      () => store.selected,
      (v) => console.log('new selected', v, Date.now() % 1e8)
    )
  );

  onMount(() => {
    // This does trigger
    setTimeout(() => {
      setStore('selected', ['abc', 'def']);
    }, 2000);
    // This doesn't trigger
    setTimeout(() => {
      setStore('selected', reconcile(['abc', 'def']));
    }, 4000);
    // This doesn't trigger store.selected because the array is preserved
    setTimeout(() => {
      setStore('selected', reconcile(['abc', 'def', 'ghi']));
    }, 6000);
  });

  return <p>{store.selected}</p>;
}

function App() {
  const [store, setStore] = createStore({ selected: ['abc', 'def'] });

  createEffect(
    on(
      () => store.selected,
      (v) => console.log('new selected', v, Date.now() % 1e8)
    )
  );

  onMount(() => {
    // This does trigger
    setTimeout(() => {
      setStore('selected', ['abc', 'def']);
    }, 2000);
    // This doesn't trigger
    setTimeout(() => {
      setStore('selected', reconcile(['abc', 'def']));
    }, 4000);
    // This doesn't trigger store.selected because the array is preserved
    setTimeout(() => {
      setStore('selected', reconcile(['abc', 'def', 'ghi']));
    }, 6000);
  });

  return <p>{store.selected}</p>;
}

hyperknotOP•2w ago

Now this one definitely puzzles me (// This doesn't trigger store.selected because the array is preserved) Why is it?

peerreynders•2w ago

Because applyState preserves the original array (i.e. preserves the array's “referential equality”) and just adds a new element to the end. The array didn't change; its content did. So if it is important that change propagates when anything inside the array changed, you are better off changing the array that everything is stored in.

GitHub

solid/packages/solid/store/src/modifiers.ts at 41fa6c14b4bf71eed593...

A declarative, efficient, and flexible JavaScript library for building user interfaces. - solidjs/solid

hyperknotOP•2w ago

I think it does trigger, it just doesn't trigger the createEffect: https://playground.solidjs.com/anonymous/0ed192e0-1eba-4969-88c5-8abe61896944

Solid Playground

Quickly discover what the solid compiler will generate from your JSX template

hyperknotOP•2w ago

It seems to be a limitation of createEffect, not setStore / reconcile

peerreynders•2w ago

No, For subscribes to the length of the array and each individual array element as well.

hyperknotOP•2w ago

but that is the correct way to track an array, isn't it? I mean for performance reasons, I want to avoid unecessary signal updates as much as I can. So I'm thinking of using reconcile everywhere. But then createEffects won't work.

peerreynders•2w ago

Look at this addTodo. The entire array is replaced when a single new todo is added. That is a deliberate implementation choice to support the way the app works. Indiscriminate reconcile isn't the way to go.

GitHub

solid-todomvc/src/index.tsx at f48302376244513396de3e353e73ba136151...

Solid implementation of TodoMVC. Contribute to solidjs/solid-todomvc development by creating an account on GitHub.

peerreynders•2w ago

Reactivity needes to be structured in a very deliberate manner. “Everything is reactive” will simply have your code tippy toeing in a mine field.

hyperknotOP•2w ago

I'm reading the TodoMVC app, but first I'm trying to understand what's happening here: https://playground.solidjs.com/anonymous/cbaca548-0499-44b5-851b-f98ff0abc470 The DOM is updated, the "direct" console line is printed, only the "on" version is not.

Solid Playground

Quickly discover what the solid compiler will generate from your JSX template

peerreynders•2w ago

createEffect(() => {
  const data = store.selected;
  untrack(() => console.log('direct', data, Date.now() % 1e8));
});

createEffect(() => {
  const data = store.selected;
  untrack(() => console.log('direct', data, Date.now() % 1e8));
});

In the original the store.selected .toString() was implicitly used inside a tracking context. So that effect also subscribed to any of the array properties that .toString() accessed. Basically using on this way is foreshadowing what is going to happen with Solid 2.x impure/pure separation.

hyperknotOP•2w ago

OK, I understand this part, it's like how we always have to write the full props.... versions with long variable names, we cannot just use local variables in Solid components.

peerreynders•2w ago

That relates to breaking reactivity. Full props path ensures that you go back all the way to the source rather than just using a value that was copied at the time of destructuring- not really related.

hyperknotOP•2w ago

OK, I read the untrack docs, it's something different. I never used untrack before.

peerreynders•2w ago

untrack - just give me your current values; NO I don't want to subscribe to anything so that you can rerun me later; this is a one off. I often use it when callbacks are passed via props

hyperknotOP•2w ago

I see

peerreynders•2w ago

I went through the following phases: - signals are great - stores are better - wait a minute, signals are quite often good enough. Signals are very predictable. Stores can be tricky because they are based on proxies. Whenever you drill down (reading) inside a store within a tracked context you automatically subscribe to all the intermediary parts of the access path. And at times proxied arrays don't behave like you expect arrays to behave because you are accessing them through a proxy.

hyperknotOP•2w ago

Right now, I feel happy to use stores for like 99% of things, except state which is very much scoped to a UI component. But I understand it might not be the ideal solution for everything.

peerreynders•2w ago

Have alook at this

proxyToArray.push('Test');

proxyToArray.push('Test');

Causes all this:

getting push for 
getting length for 
setting 0 for  with value Test 
setting length for Test with value 1

getting push for 
getting length for 
setting 0 for  with value Test 
setting length for Test with value 1

Stack Overflow

Detecting changes in a Javascript array using the Proxy object

It is relatively trivial to watch for changes in an array in Javascript. One method I use is like this: // subscribe to add, update, delete, and splice changes Array.observe(viewHelpFiles, function(

peerreynders•2w ago

In many cases when you think in terms of what change do I need to propagate focusing on values via signals is often good enough. Not to mention that derivations like memo, props, etc tend to behave more like signals anyway.

hyperknotOP•2w ago

I've read the SO question, but I think Solid is protected from this, isn't it? Basically setState makes sure you are treating everything like an immutables, isn't it?

peerreynders•2w ago

Basically setState makes sure you are treating everything like an immutables, isn't it?

I'm not sure what you mean (as setStore does mutate the store's underlying data while at the same time queuing up the listeners that are interested in the relevant parts of the data). The way I view it is that Solid treats mutability as a superpower that comes with responsibilities. And in order to compensate for the loss of guarantees that are associated with immutability, Solid promotes read/write segregation.

Precise control and predictability make for better systems. We don't need true immutability to enforce unidirectional flow, just the ability to make the conscious decision which consumers may write and which may not.

- Giving access to an accessor does not expose the risk of mutation. - Having access to an (reactive) accessor also guarantees timely notification if and when the source value is modified so there is no risk of depending on an outdated value.
- Mutation (setters) can be easily restricted to only those sites which absolutely need it, so mutation is a privilege that is controlled separately from access. So it's accessors which are seen as immutable in a way; with the understanding that any code that accesses them will be rerun the moment the dependency changes. Read/write segregation serves unidirectional flow the benefits of which were discussed way back with the flux architecture presentation. Paying attention to unidirectional flow is also important to avoid constructing infinite, reactive loops.

Meta Developers

YouTube

Hacker Way: Rethinking Web App Development at Facebook

Delivering reliable, high-performance web experiences at Facebook's scale has required us to challenge some long-held assumptions about software development. Join us to learn how we abandoned the traditional MVC paradigm in favor of a more functional application architecture.

SolidJS

Solid is a purely reactive library. It was designed from the ground up with a reactive core. It's influenced by reactive principles developed by previous libraries.

hyperknotOP•2w ago

What I meant is that the SO post shows the dangers of using proxies directly. Now AFAIK Solid doesn't allow anyone to do this, we can only modify it with setState. So none of the dangers in the SO post apply to us (or I didn't quite understand the SO post) I started watching the flux video, haven't finished it yet.

peerreynders•7d ago

I was originally looking for this: https://stackoverflow.com/questions/59715892/when-proxying-an-array-and-accessing-the-map-function-why-is-the-arrays-const Consequently when running .map() on an array in a store inside a tracked context you're inevitably subscribed to all the following properties of that array: map, length, constructor, 0, 1, 2, 3, … etc.

Stack Overflow

When proxying an array, and accessing the map function, why is the ...

I'm creating a proxy of an array, and then calling .map on the proxy to iteratively retrieve the elements in the target array: const proxiedArray = new Proxy([...], { get: function(target, pro...

hyperknotOP•6d ago

Interesting, so map() is tracking everything, good to know!

Gaming

Programming

Does store setState check for equality before updating signals?

Did you find this page helpful?