adds equals:true

[titoBouzout]

Summary

Theres createMemo(() => props.value, { equals: false })
This PR adds the reverse, createMemo(() => props.value, { equals: true }), which effectively stops the memo from updating.

Its done by creating a new function isAlwaysEqual similar to the current isEqual, and using it when equals:true.

The motivation, is having a core way to stop things from being reactive (similar to how things can be declared overly reactive with equals: false ).

It kills the need for a createOnce.

const initial = createMemo(() => count(), {equals: true})
return <div data-initial={initial()} data-current={count()}/>

Disclaimer, made it with claude.

Claude attempted to unlink the computation from recompute() function, possibly an optimization, but made it back off from that as I would prefer you do these optimizations yourself.

How did you test this change?

added tests
pnpm test

[ryansolid]

I'm not sure this is necessary.. this is to save writing { equals: () => true }. However this does encode a different semantic meaning. I suppose equals false does as well if you take createMemo to literally mean its a memo. But if you take it to mean a derived computation then the decision to bypass(or provide) default equality seems reasonable. This just never notifies and sits there and recomputes over and over.

What you really want I think is:

const initial = createMemo(() => untrack(count));

Which will not create the dependency unless its originally async, then when it resolves it will have the updated value.

I guess the setter writes is the one exception for why you would override equality but I'm not really following generally. Like isn't untrack the core way we stop stuff from being reactive?

[titoBouzout]

That sounds reasonable, but its incredible verbose

const initial = createMemo(() => untrack(() => props.count ));

Having it as equals: true would be intuitive (the opposite of equals:false) and easier to write

[ryansolid]

Yeah im standing by my first take. Having it rerun over and over just not to commit doesn't feel like the objective. You want the untrack behavior. And if on some odd scenario someone really wanted equal frue it is only an extra function wrapper. I dont think this behavior is worth streamlining through special means.