#Understanding Solid reactivity with console.log

34 messages · Page 1 of 1 (latest)

ivory shadow
#

I'm using createMemo with a console.log inside. Can you tell me why is this console.logging all the items, when I click on one?

Am I using createMemo in a wrong way? I thought only the 2 changed items would be recalculated.

I created a Stackblitz + GitHub repo to undestand this better:
https://stackblitz.com/~/github.com/hyperknot/solidjs-sandbox

This is the line with the console.log
https://github.com/hyperknot/solidjs-sandbox/blob/a19b9581595bedd7b5e7949560a7b0d0755b8fd7/src/1-simple/store/doc.js#L15

stable elm
#

I'm still trying to decypher the code to understand why your memo is triggering for each and every click. A couple of things that I initially spot that might or might not be a cause of your bug:

  1. the circular dependency of uistate.js and doc.js is either already, or will in the future, cause you problems
  2. why are you calling createRoot? this is a helper from solid which in meant to initialize the reactive system, so normally you only do this once in order to 'mount' solid to the DOM.
#

aaaaah, I see why, you are using uiStore.state.activeDocID inside of your memo. since the uistore is also a reactive store this means that your memo is tracking both the internal store of the doc itself. and also the uistore. This is also the behavior you want, because otherwise your isActive would never update.

#

so to summarize, the reason you are seeing all the numbers being logged is because each and every Doc is answering the question if it is active or not.

#

if you just wish to log the one or two Doc's that actually changed than you want to add a createEffect that logs the isActive memo. then you would only see the numbers that did change

manic bone
#

its purpose is exactly so that you don't need a memo for each isActive

#

would look something like ```tsx
const isActive = createSelector(() => store, (doc, store) => store.activeDocID === doc.uuid)

manic bone
#

to prevent that cannot cleanup computations outside of ... warning

stable elm
#

aaaah, gotcha

manic bone
#

although iirc that warning is only there when u have computations/memos/effects

stable elm
#

just for my understanding than. isn't it bad practice to create that stuff outside of the render tree? I always avoid creating top level signals and such for the same reason. or at least I think it is for the same reason

manic bone
#

it's a bad practice if you use SSR

#

because then you can accidentally create shared data between sessions

#

but if you are client-only you can definitely use it

#

that pattern of creating a module with a store and importing the store + actions is called a singleton in solidjs

#

i use it all the time, it's a pretty awesome way of doing global state, no hassle with contexts and stuff

manic bone
#

but this ```tsx
return <div onClick={() => createEffect(...)}/>

#

because then an effect is made (and never cleaned up) on each click

#

the circular dependency of uistate.js and doc.js is either already, or will in the future, cause you problems
this is very true tho and probably something you need to address

stable elm
ivory shadow
#

Thanks for all the answers! I'm still trying to wrap my head around it. What I definitely want to avoid is to create a 1000 roots. I think that's not good for performance, right?

Also, I understand that createSelector exists, but I'm trying to learn createMemo first.

This app is a pure Vite client side SPA.

So are you saying that even though the console.log runs for all items, actually not every item is updated?

I'm basically trying to understand how to minimise "re-renders" in Solid, even though it doesn't re-render. But it still updates DOM elements, doesn't it? So how can I minimise those repaints or DOM updates?

stable elm
#

depends on what you mean as a rerender. like an actual render that you could make visible with devtools? or do you mean the reactivity system doing its job?

#

because with your memo you should only get 2 items that actually rerender, the one that loses the active state, and the one that gets it

#

but all your items run the memo itself to calculate if there is a change

ivory shadow
#

so in this example it probably makes no sense to use any kind of advanced function. but what if it takes some computation. say it's a tree view and I need to recalculate all the subtrees. how can I make sure that only the changed items are recalculated, and not all of them?

I'm also trying to get to the root of it via devtools but it seems an even more complicated subject.

#

so basically I'm trying to learn what's happening behind the scenes, to avoid unnecessarily, potentially slow calculations

stable elm
stable elm
ivory shadow
#

I understand. But still, generally when trying to debug what can cause performance slowdowns, how should I approach it? Adding a createEffect() inside components and adding console.log? Or trying to figure out the logging component of the devtools package?

stable elm
long gyro