SolidJS•11mo ago

createSignal equals: false on mutable object value

Hi guys,

I have a resource source signal with { equals: false } that does not trigger fetching unless I wrap and deep copy the object literal value in the source param.

The value itself is a propety of an instance wrapped with

createMutable

createMutable

, which I suspect is at the crux of this.

But why? I though

equals: true

equals: true

would guarantee a truthy source signal on setting?

const muatable = createMutable(myClassInstance)
[...]
const [onSaveSignal, setSaveSignal] = createSignal(mutable.data, { equals: false })
[...]
createResource(
   onSaveSignal,
   (sigObjValue) => {
     fetch...
   }
);

const muatable = createMutable(myClassInstance)
[...]
const [onSaveSignal, setSaveSignal] = createSignal(mutable.data, { equals: false })
[...]
createResource(
   onSaveSignal,
   (sigObjValue) => {
     fetch...
   }
);

Above not working, below working.

createResource(
   () => deepCopy(onSaveSignal()),
   (sigObjValue) => {
     fetch...
   }
);

createResource(
   () => deepCopy(onSaveSignal()),
   (sigObjValue) => {
     fetch...
   }
);

shallow structuredClone also fails.

REEEEE•2/6/25, 3:39 PM

Signals definitions aren't reactive meaning that won't be updated with the latest when it changes

FlemmingOP•2/6/25, 3:40 PM

Hmm, still the isgnal triggers as I can debug from within { equals: () => { ... })

REEEEE•2/6/25, 3:41 PM

If you're writing to the signal somewhere, it will still fire the equals check

FlemmingOP•2/6/25, 3:41 PM

Yes, that is the case. Therefore I assumed { equals: false } would work.

REEEEE•2/6/25, 3:42 PM

How are you writing to the signal?

FlemmingOP•2/6/25, 3:42 PM

REEEEE•2/6/25, 3:43 PM

Hmm

REEEEE•2/6/25, 3:43 PM

Looks like

createResource

createResource

will memo the source signals

FlemmingOP•2/6/25, 3:44 PM

Sth along those lines would explain it, but reading the documentation, that is excatly what { equals: false } should circumvent?

REEEEE•2/6/25, 3:44 PM

maybe a small change that could work is to do

REEEEE•2/6/25, 3:45 PM

The memo has it's own

equals

equals

handling

REEEEE•2/6/25, 3:45 PM

By default it checks via

===

===

FlemmingOP•2/6/25, 3:48 PM

I tested now, just give me a few sec to double check that I have doen it right...

FlemmingOP•2/6/25, 3:50 PM

Yes that works with { equals: false }

FlemmingOP•2/6/25, 3:51 PM

But, this should also work without { equals: false } ? Due to shallow comparison?

REEEEE•2/6/25, 3:52 PM

yeah it should but you have to make sure when you set it's a new obj

REEEEE•2/6/25, 3:53 PM

otherwise the signals default equality

===

===

will pass

FlemmingOP•2/6/25, 3:54 PM

Hmm, I see what you mean, but then the case is that { equals: false } is a bit misleading? It swithches from deep (?) to shallow checking, or s.th?

FlemmingOP•2/6/25, 3:55 PM

Nah, the docs explicitly says that it will overrride whatever.

REEEEE•2/6/25, 3:55 PM

{equals: false}

{equals: false}

is to explicitly make it so no matter what you set the value to (it could literally be the same value again), it will trigger anything that's listening to the signal

FlemmingOP•2/6/25, 3:56 PM

Okay, see your point

FlemmingOP•2/6/25, 3:56 PM

There is another memo in the resource source

FlemmingOP•2/6/25, 3:56 PM

*on

REEEEE•2/6/25, 3:57 PM

Memos have the same equals handling but you have to also set that yourself but

createResource

createResource

doesn't expose a way to set that right now

REEEEE•2/6/25, 3:57 PM

In the eyes of the memo for resource, your previous object and your next object are equal so it doesn't rerun

REEEEE•2/6/25, 3:57 PM

Because they're the same obj

FlemmingOP•2/6/25, 3:59 PM

Yup, I understand!
Thank you very much for taking the time!

REEEEE•2/6/25, 3:59 PM

No problem!