-
Notifications
You must be signed in to change notification settings - Fork 9
Add a useSignalEffect implementation that behaves like useEffect
#226
Conversation
|
I've been trying to add tests to reproduce the problem here and to reproduce that I needed a newer version of The good news is that the new |
|
I couldn't use This should be ready now. As you started the PR, I've preapproved it. Feel free to review and merge 🙂 |
|
Oh, the tests pass on my computer but not here. I don't know what's going on. |
|
Well, I ended up:
Things should be ready now. |
DAreRodz
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @luisherranz! The changes you did look great to me. 😄
src/runtime/directives.js
Outdated
| Object.entries(on).forEach(([name, path]) => { | ||
| element.props[`on${name}`] = (event) => { | ||
| evaluate(path, { event, context: contextValue }); | ||
| return evaluate(path, { event, context: contextValue }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This return is not needed; I'm pretty sure event listener callbacks always return undefined (see this). I'll change this, don't worry. 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I see. So instead of returning false in the onclick attribute, you'd use event.stopPropagation() in the event listener. And Preact is using the listener, not the attribute, right?
The current
useSignalEffecthook implementation from @preact/signals calls the passed callback before changes to the DOM are made, but it should wait for DOM changes (likeuseEffectdoes).I just copy-pasted the
useSignalEffecthook and its dependencies from preactjs/signals#290 until those changes are merged and released in @preact/signals.