Yeah Solid doesn't even have an isObservable. All we do is wrap things in functions. If it is a function it could be reactive so call it in a computation.. Otherwise just execute the expression. I know that if there are no member expressions or no call expressions it doesn't need to be wrapped. For components I do the same thing except instead of using computation I literally assign it to the props objects, and things that need to be wrapped are put in a getter.
This all seems like it would add some overhead but because we group attribute reactivity in templates as long as something is reactive you haven't created anything extra that has meaningful impact. It also isn't fragile since it is deoptimized by default. It will always work, just often it can work better. And this somehow is still performant enough for the common cases. The worst case is you create a couple computations that only run once and never update.
In essence we don't generally even really rewrite the JS expressions passed in to the JSX. We just choose whether or not to wrap them in functions based on a very simple heuristic. So all the JavaScript expressions execute the way they are written. The only exception of that is handling ternary/boolean operators that branch to things that would be wrapped. We do independently wrap the condition in those cases in a computation to prevent repeated execution. I honestly wasn't intending to go this way but since it is completely analyzable and people like this shorthand (instead of using our <Show> component) it was a reasonable addition.
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.
Yeah Solid doesn't even have an
isObservable. All we do is wrap things in functions. If it is a function it could be reactive so call it in a computation.. Otherwise just execute the expression. I know that if there are no member expressions or no call expressions it doesn't need to be wrapped. For components I do the same thing except instead of using computation I literally assign it to the props objects, and things that need to be wrapped are put in a getter.This all seems like it would add some overhead but because we group attribute reactivity in templates as long as something is reactive you haven't created anything extra that has meaningful impact. It also isn't fragile since it is deoptimized by default. It will always work, just often it can work better. And this somehow is still performant enough for the common cases. The worst case is you create a couple computations that only run once and never update.
In essence we don't generally even really rewrite the JS expressions passed in to the JSX. We just choose whether or not to wrap them in functions based on a very simple heuristic. So all the JavaScript expressions execute the way they are written. The only exception of that is handling ternary/boolean operators that branch to things that would be wrapped. We do independently wrap the condition in those cases in a computation to prevent repeated execution. I honestly wasn't intending to go this way but since it is completely analyzable and people like this shorthand (instead of using our
<Show>component) it was a reasonable addition.