[Note: it’s often unclear to me why so many Show HN posts show up dead on, or very soon after, arrival. I vouched for this, not because I’m interested in it but because it seems like a perfectly cromulent post.]
This is really interesting! It’s not something I would necessarily choose for a personal or greenfield project, but it might fit well in a project I inherited/maintain which already has a ton of imperative DOM code.
Particularly interesting to me is the `from` API for treating actual DOM nodes/native event sources as reactive inputs. This would work quite well in my project, which currently relies much more than I’d like on native (and ugh, jQuery) event handlers. While I personally prefer a functional style, this imperative design would still be easier to reason about than current events usage, and could conceivably be part of a more gradual strategy towards a more functional future.
[Yeah me too, but nevertheless, I thought this result might be interesting to some people so it doesn't hurt sharing it]
Thanks a lot! Yeah the original idea was from "rxjs-autorun" basically, and I think the idea got subsequently incorporated into SolidJS (if I'm not mistaken). Here basically I wanted to test effect of some additional constraints on the idea, specifically the interaction with async contexts which was missing before, which turned out pretty interesting.
I personally prefer a functional style as well, but time and again have been forced to isolate and heavily explain such FRP code in team projects to accommodate for other teammates who might not feel comfortable with the style. This is why this thread of "flattening" reactive programming into a more imperative style has been fascinating me for quite some time now.
Looking forward to hearing your feedback on how it will turn out in your project!
FWIW, Solid has been for some time under consideration for gradually untangling state in this project. Another library I’ve explored is element-behaviors[1], a Solid/custom element-based Entity Component System, which I think could be a good model for the project.
Regardless of what tech I pull in, I’m sure I’ll be sharing insights eventually!
3 comments
[ 3.8 ms ] story [ 20.7 ms ] threadThis is really interesting! It’s not something I would necessarily choose for a personal or greenfield project, but it might fit well in a project I inherited/maintain which already has a ton of imperative DOM code.
Particularly interesting to me is the `from` API for treating actual DOM nodes/native event sources as reactive inputs. This would work quite well in my project, which currently relies much more than I’d like on native (and ugh, jQuery) event handlers. While I personally prefer a functional style, this imperative design would still be easier to reason about than current events usage, and could conceivably be part of a more gradual strategy towards a more functional future.
Thanks for sharing!
Thanks a lot! Yeah the original idea was from "rxjs-autorun" basically, and I think the idea got subsequently incorporated into SolidJS (if I'm not mistaken). Here basically I wanted to test effect of some additional constraints on the idea, specifically the interaction with async contexts which was missing before, which turned out pretty interesting.
I personally prefer a functional style as well, but time and again have been forced to isolate and heavily explain such FRP code in team projects to accommodate for other teammates who might not feel comfortable with the style. This is why this thread of "flattening" reactive programming into a more imperative style has been fascinating me for quite some time now.
Looking forward to hearing your feedback on how it will turn out in your project!
Regardless of what tech I pull in, I’m sure I’ll be sharing insights eventually!
1: https://github.com/lume/element-behaviors