Hacker News Reader

Comment by djbusby | Hacker News Reader

I've been using patterns like this for more than a decade. The thing that's hard is, down the road you could have a listener, which triggers a other event, then another event, which comes back to the first routine and now you got a listen-loop that won't quit.

And it's hard to ensure that all listener don't cause that trigger cascade.

View on HN

Isn't it possible to define all listeners / publishers in a declarative way which can be compiled to catch for this issues?

Yes. It is. And most pub/sub or Observer architectures and design patterns have the "loop" thing solved just fine.

In fact, the GOF spend an entire paragraph on the problem of complex update semantics in "design Patterns" (1995) ch Observer p299.

So, while it is a real problem, it's one that has been solved (for at least 29 years)

Yes, I want to mention, since I was up-thread, it is solved but not all tooling or environment are setup for that.

When the app is small you likely don't need it. And then it grows and you absolutely do.

It's better, in greenfield to use framework/tooling that is ready for it.

Good to hear you found it solved!

> It's better, in greenfield to use framework/tooling that is ready for it.

I don't really agree. Tooling, and even more so, Frameworks, come with giant trade-offs. Some are "paint-in-a-corner" trade-offs. So I would caution against pulling in a framework just to solve potential future issues. So much so, that I think it is one of the top10 things that will cause your project or startup to fail or get into serious trouble. It's really a form of "premature optimization".

In fact I solved a similar issue in my JS reactive micro library in just 500 bytes: https://github.com/jbreckmckye/trkl

I was not aware of trkl. Well done! I wrote rmemo (Reactive Memo) which solves the same problems & is a similar size. Different semantics though.

https://github.com/ctx-core/rmemo

Nanostores is also small https://github.com/nanostores/nanostores.

And if you only need reactivity in the browser (not server side), VanJS is small & includes reactive primitives. https://vanjs.org/

That looks great! Thanks for sharing!

I like signals as primitive but in this particular case they make it roughly about as easy to create loops accidentally as events do. I don't think this problem gets better or worse with signals.

Signals are a bit better because they only propagate when computed values actually changed. This is an implicit fixed point/stopping condition that doesn't intrinsically exist with events.

Reply on news.ycombinator.com