New primitive to reduce code re-execution and maximize performance

[AFatNiBBa]

Let's suppose I have this very simple application

import { createSignal, createEffect } from "solid-js";
import { render } from "solid-js/web";

const [get, set] = createSignal(0);

createEffect(() => {
  console.log("Executed", get());
});

render(
  () => <button onClick={() => set((x) => x + 1)}>Add</button>,
  document.getElementById("app")!,
);

Each time I click the button, "Executed" will be logged followed by the current number, this is all optimal.
Now let's suppose that now for some reason my applications requires the number 7 to be skipped inside that effect, I could change the onClick event like so

set((x) => x + (x === 6 ? 2 : 1))

But for the semplicity of the argument let's say that I have no control over that handler or that it is not logically correct for my specific application to change the logic of said handler.
I could achieve the same result through the effect by doing this

var value = get();
if (value === 7) value = set(x => x + 1);
console.log("Executed", value);

But this has one side effect: The execution of set() will cause the current effect to be invalidated, since get() is one of its dependencies, so it will be executed two times and the console will log

...
Executed 6
Executed 8
Executed 8
Executed 9
...

Instead of

...
Executed 6
Executed 8
Executed 9
...

Moreover, this is not needed since I ensure to mutate the value variable after I increase the Signal, thus already considering the side effects of my special case.
This could be fixed by a new primitive: assumeConsidered()

var value = get();
if (value === 7) value = assumeConsidered(() => set(x => x + 1));
console.log("Executed", value);

It would assume that the side effects of ONLY what's inside the provided function will be assumed to be already handled, this will also ensure that the presence of something that wasn't handled preventively would still trigger the second execution

var value = get();
if (value === 7) {
  set((x) => x + 1);
  value = assumeConsidered(() => set((x) => x + 1));
}
console.log("Executed", value); // It would log the number `9` two times

Since I needed this functionality, I already made an implementation myself, and I thought it would have benefitted the whole ecosystem if used correctly

/**
 * Executes a function assuming that all its side effects have already been considered by the current effect.
 * If a reactive value is read and written during the execution of a given effect, each write will always trigger AT LEAST a new execution, even if potentially the effect of the write was already taken into account.
 * This function executes {@link f} and RESTORES the state of the current effect to what it was before the execution, so if it was "dirty" already it will still be re-executed, while in normal cases it is assumed that the user of the function has already handled the case.
 * To minimize the risk of data misalignment, it should be used in extremely specific points of the code, where it is certain that side effects will be handled preventively
 * The execution of {@link f} will be under {@link batch} to prevent side effects from possibly being run synchronously (Before the effect state is restored)
 * @param f The function to execute
 * @param listener The current effect computation
 * @returns The same thing that {@link f} returned
 */
export function assumeConsidered<R>(f: () => R, listener = getListener()): R {
  if (!listener) return f();
  return batch(() => {
    const { state } = listener;
    try { return f(); }
    finally { listener.state = state; }
  });
}

The reason it can also accepts the computation as an argument is because, in my codebase, I needed to both execute untrack() and assumeConsidered().
I could've done it like this

assumeConsidered(() => {
  untrack(() => {
    // Thing that reads
    // Thing that writes
    // Thing that reads
  });
});

But I wanted to reduce the "ignored" area as much as possible

untrack(() => {
  // Thing that reads
  assumeConsidered(() => {
    // Thing that writes
  });
  // Thing that reads
});

Unfortunately I can't do that because untrack() removes the listener, so I did this

const l = getListener();
untrack(() => {
  // Thing that reads
  assumeConsidered(() => {
    // Thing that writes
  }, l);
  // Thing that reads
});

My implementation doesn't consider nested effects, it that case it might be correct to also restore the state of the parent ones

[atk]

To reshape the reactivity of your signals, you got createMemo:

import { createSignal, createEffect, createMemo } from "solid-js";
import { render } from "solid-js/web";

const [get, set] = createSignal(0);
const memo = createMemo(() => get() === 6 ? 7 : get());

createEffect(() => {
  console.log("Executed", memo());
});

render(
  () => <button onClick={() => set((x) => x + 1)}>Add</button>,
  document.getElementById("app")!,
);

There are also a few more reactive helpers in https://primitives.solidjs.community/, so if there are any more pieces you are missing, you might be able to find them there.

[AFatNiBBa]

How can I derive the value if I have two editable datasets that need to be joined and one of them is also dependent on the other?
Those object with signals were made for the example, in reality I use a custom version of mutables.
The reason I don't use the normal ones is because I need them to work with classes and the getters to be memoized.
I need that because my application converts a very large amount of interconnected Excel spreadsheets to JavaScript classes, if they weren't memoized they would not only be REALLY slow, but they would be SO MUCH slow to make the web page crash

[atk]

Class instances are a huge overhead compared to plain objects and arrays (which are fairly optimized), so I'm not too surprised that you have a performance issue.

Though there might be a performance issue even then, I don't know your actual case. But then, why not handling the data conversion on the server?

[AFatNiBBa]

Classes are not an issue in the slightest from that point of view.
Imagine 100+ spreadsheets with 1 to 3 sheets on average, each filled to the brim of unoptimized formulas wrote by accountants that have absolutely ZERO knowledge about optimization.
On top of that, each result is used tens of times by other formulas, without memoization it would have been like the very much worse version of the recursive fibonacci function implementation.
WITH memoization, it's actually very fast, THOUSENDS of times more than the previous version.
This is why I don't think that classes have anything bad to do with this, on the contrary it would be worse without them, since each spreadsheet might be instanced multiple times, and each getter would otherwise be a different function instance instead of one on the prototype.

The data conversion is not handled on the "server" because we make reactivity take care of updating other things when the source lists get modified, which never happens on the two lists at the same time

[atk]

Even getters are a performance overhead, albeit manageable. And do you believe you cannot store memos inside objects?

[AFatNiBBa]

We use classes insead of objects for various reasons:

• The Excel-to-class conversion happens during build: We do NOT generate classes dynamically at runtime, we generate the actual class source and store it to a file for later use. Since we generate the actual code, using classes helps debugging
• We need to instantiate those converted spreadsheets more than once, so we wanted to use classes since that is their purpose
• We have different types of spreadsheets (Let's not get too much into details) so we take advantage of inheritance to express the branching of functionalities in an orderly manner

I would like to know the kinds of overheads you're referring to, but I think they're not related to the discussion: Even if my whole app were to never use classes, I would still want those memos to not be executed multiple times