-
-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unregister JSX effects #9
Comments
This is the faling test (marked as todo): https://github.com/aralroca/brisa/blob/480576d2d28689af4cccea55d76041d98e0fb8ff/src/utils/transform-jsx-to-reactive/integration.test.ts#L2331-L2375 |
@amatiasq I think this could be a solution, although before implementing it, I will think about it in case we find a better one. Tell me please what do you think about this proposal. Possible solution (proposal)We can upgrade the build from: return h('div', {}, () => user.value && ['b', {}, () => `Name: ${user.value.name}`]); to something like this: return h('div', {}, (r) => user.value && ['b', {}, r(() => `Name: ${user.value.name}`)]); and then in runtime register all the subeffects of each effect, and whenever it is executed in effect that first eliminates all its subeffects. In the same way as if the developers use the effects of this style (rare case): effect(() => {
if(someSignal.value) {
effect(() => {
console.log(someSignal.value, anotherSignal.value);
})
}
}) could be transformed during build to: effect((r) => {
if(someSignal.value) {
effect(r(() => {
console.log(someSignal.value, anotherSignal.value);
}))
}
}) correcting later in runtime. There will never be many cases of nesting in JSX since each web component is isolated from the others. However, if there are more than 2 nesting levels: effect((r) => {
if(someSignal.value) {
effect(r((r2) => {
if(anotherSignal.value) {
effect(r2(r(() => {
console.log(nested.value)
})))
}
}))
}
}) One change I've made that would help with implementationCurrently, the effects are registered within each state: This makes it impossible to delete subeffects from the execution of an effect. Besides, just I noticed an issue that the cleanAll is not deleting the effects. And the cleanAll is called when the component is unmounted. To fix this I did this PR #10. I have now moved the effects to a higher layer to have control of them, and this way I have been able to solve the issue of unregistering all the effects when doing unmount. So after this change, it will make it easier to implement this proposal. |
It is a good idea, I'm not grasping it full since I can't see what But yeah, moving the effects to the parent closure opens a whole new way of addressing this problem. |
I realized that at JSX level it is not necessary to make any change at build level, because the Brisa element
|
All the effects are registered when the signal get is dispatched. However, we don't have a way to unregister it. An example is this:
This is the transformed JSX in the return statement after the build:
In runtime, each function is wrapped with an
effect
and is generating the DOM elements. This is why each time that a signal changes, the effect is running and updating the DOM elements.However, now if the
user
changes tonull
, this effect that is already registered is fired again:The text was updated successfully, but these errors were encountered: