Signal/Effect vs Event Handler I’m working in a VanillaJS…
0 reactions
Signal/Effect vs Event Handler
I’m working in a VanillaJS repository (plugin type code for an existing project that I do not own) where I’ve written a signal implementation.
Today I was working on a tooltip like implementation and I found myself wondering how far to go with the signal/effect ecosystem vs running the “core” logic in the event handler.
The implementation detects the \`<tr>\` that the user has hovered and assigns that row to the “current row” signal. A computed signal identifies an IP address from the current row. An effect loads Whois metadata from the IP and assigns it to a \`<div>\`, and another effect shows that \`<div popover>\` from the parent \`<tr>\`.
The question I have is when in VanillaJS how would you decide when to use signals and effects vs writing the side effect directly in the event handler? In my case I find either to be equally readable, though I have less local variables to deal with when using signal/effect. Looking for reasons your might pick one over the other.
#programming #dev #js #technology
source
I’m working in a VanillaJS repository (plugin type code for an existing project that I do not own) where I’ve written a signal implementation.
Today I was working on a tooltip like implementation and I found myself wondering how far to go with the signal/effect ecosystem vs running the “core” logic in the event handler.
The implementation detects the \`<tr>\` that the user has hovered and assigns that row to the “current row” signal. A computed signal identifies an IP address from the current row. An effect loads Whois metadata from the IP and assigns it to a \`<div>\`, and another effect shows that \`<div popover>\` from the parent \`<tr>\`.
The question I have is when in VanillaJS how would you decide when to use signals and effects vs writing the side effect directly in the event handler? In my case I find either to be equally readable, though I have less local variables to deal with when using signal/effect. Looking for reasons your might pick one over the other.
#programming #dev #js #technology
source
| 0 mlx | |
| 1 | |
| 0 |