S
SolidJS4mo ago
gsoutz

I've shot myself in the foot again.

Help. I don't know what signal is causing which effect or why they are triggered thrice on each change.
11 Replies
REEEEE
REEEEE4mo ago
Use on or untrack to only track the signals you want the effect to track
gsoutz
gsoutz4mo ago
I can't track where the signals are accessed at what point, which ones are untracked or tracked where, it's hidden into abstractions . I need a structure that designates how to build an abstraction system for signals and memos, and effects that use them.
gsoutz
gsoutz4mo ago
I have something like this https://playground.solidjs.com/anonymous/bb2d73e4-ddc3-4d92-b22b-e0c06af28d8d Except it's not quite what I want. Please fix this.
Solid Playground
Quickly discover what the solid compiler will generate from your JSX template
peerreynders
peerreynders4mo ago
Solid Playground
Quickly discover what the solid compiler will generate from your JSX template
bigmistqke 🌈
bigmistqke 🌈4mo ago
the reproduction does not have the bug, right?
gsoutz
gsoutz4mo ago
no i didn't post a buggy code. I posted something I was trying to do but not quite achieved it. the reproduction makes no improvement over anyway. it's useless. I already moved on.
bigmistqke 🌈
bigmistqke 🌈4mo ago
ok sure
gsoutz
gsoutz4mo ago
It works for now, but this reactivity structure is too brittle and may not easy to maintain later..
bigmistqke 🌈
bigmistqke 🌈4mo ago
yes, it's what I was referring to the previous time it can get a bit tricky to follow the data-flow with getters and setters
peerreynders
peerreynders4mo ago
Your reproduction seems to be the result of an X Y problem—i.e. you are presenting your solution attempt to a problem that you haven't even shared with us yet. One thing that immediately jumped out was this:
// I need to merge Me's at some point for saving in the end.
createEffect(on(() => working().progress, () => {
base().merge_mee(working())
}))
// I need to merge Me's at some point for saving in the end.
createEffect(on(() => working().progress, () => {
base().merge_mee(working())
}))
You're connecting one signal's accessor to another signal's setter inside an effect which is strongly discouraged because it leads to sub-optimal results with the reactive runtime. In your mind you've equated signal setters to set properties and accessors to get properties, to be joined with effects; that is not going to work (and isn't encouraged). What you should be building is a (synchronous) reactive graph where signals only exist at the edge of the graph as inputs. Any further reactive computation takes place as derived values or memos. Finally effects are the outputs of that reactive graph which is how it manipulates the outside world (but not itself).
gsoutz
gsoutz4mo ago
this is a very cool story but it doesn't solve my actual problem. of course i have signals as well as memos all over the place, i use whatever is appropriate.