I would point out that a lot of the surprise comes down to the semantics of the function names.
I too have seen bugs come from failure to understand that React's changes are scheduled later. I submit that the reason React's result is so surprising for many devs is that the name setCount (and it being widely documented by React and others as a setter function) strongly suggest that it will, you know, set the value of count and do it now — not after this render call returns, not a few milliseconds after that, but immediately. Otherwise how can the code have a predictable execution context? And if it doesn't set count now, then why is it referred to as a setter function, named setCount? The naming semantics are bad.
Svelte similarly fails on semantics and perhaps false promises. It sets count immediately, but then doubleCount — which is supposedly is derived from count — is not recomputed immediately and is therefore inconsistent its own name — doubleCount is no longer double the value of count.
Variable and function names are important for understanding code and communication design contracts. Any time a function or variable doesn't have the behavior or value indicated by its name is a sure sign that something is amiss, and bugs are likely to follow.
So I would say that of the above approaches, Solid is doing it right. Yes, that may sometimes involve some redundant calculations and a little less efficiency. But if the second function returned by createSignal is going be called a setter function — with a convention of being named setSomething — then it better damn well set that something immediately, each and every time that it is called. There's too many decades of precedent in this matter for a setter function to do anything else.
Wanna have a batch mode for maximal efficiency? Fine, but make it a new variant of signal — e.g. createDeferredSignal — and change the docs for that to suggest that the second function returned by it should be called updateSomething to indicate that such updates will not be immediate. Then it should be sufficiently clear that recompilation of any memos derived from that deferred signal will not be immediate either.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I would point out that a lot of the surprise comes down to the semantics of the function names.
I too have seen bugs come from failure to understand that React's changes are scheduled later. I submit that the reason React's result is so surprising for many devs is that the name
setCount(and it being widely documented by React and others as a setter function) strongly suggest that it will, you know, set the value ofcountand do it now — not after this render call returns, not a few milliseconds after that, but immediately. Otherwise how can the code have a predictable execution context? And if it doesn't setcountnow, then why is it referred to as asetterfunction, namedsetCount? The naming semantics are bad.Svelte similarly fails on semantics and perhaps false promises. It sets
countimmediately, but thendoubleCount— which is supposedly is derived fromcount— is not recomputed immediately and is therefore inconsistent its own name —doubleCountis no longer double the value ofcount.Variable and function names are important for understanding code and communication design contracts. Any time a function or variable doesn't have the behavior or value indicated by its name is a sure sign that something is amiss, and bugs are likely to follow.
So I would say that of the above approaches, Solid is doing it right. Yes, that may sometimes involve some redundant calculations and a little less efficiency. But if the second function returned by
createSignalis going be called a setter function — with a convention of being namedsetSomething— then it better damn well set that something immediately, each and every time that it is called. There's too many decades of precedent in this matter for a setter function to do anything else.Wanna have a batch mode for maximal efficiency? Fine, but make it a new variant of signal — e.g.
createDeferredSignal— and change the docs for that to suggest that the second function returned by it should be calledupdateSomethingto indicate that such updates will not be immediate. Then it should be sufficiently clear that recompilation of any memos derived from that deferred signal will not be immediate either.