Ask HN: Qt style "Signals and Slots" based JavaScript UI library?
Are there any equivalent of Qt style loosely coupled "Signals and Slots" based JavaScript UI library? Qt allows widget/ components to be connected to each other with a pub-sub type of system where the emitter of the signal really need not care who the consumer is. While, IIUC, most JS libraries follow a hierarchically coupled state passing system where sharing of state happens through props/ passing down from parent to child components with lifted state etc., Was wondering if there are any JS libraries which operate in the style of Qt event driven signal-slot connections as a primary paradigm.
5 comments
I'm of the opinion that this is bad design because it makes it very hard to reason about the consequences when refactoring a large codebase. It's kind of like reactive global variables. There are legitimate reasons when to use them. But not as a general design principle.
That being said: If you're dead set on this paradigm you can implement this easily yourself. Create a bootstrapping function that modifies a prototype or class in order to provide functions to register signals and slots and use them wherever you need them.
If you use TypeScript you could even use Decorators (e.g. "@Signal" or "@Slot") which are just higher order functions to have some syntactic sugar like the QT macros.
That being said: If you're dead set on this paradigm you can implement this easily yourself. Create a bootstrapping function that modifies a prototype or class in order to provide functions to register signals and slots and use them wherever you need them.
If you use TypeScript you could even use Decorators (e.g. "@Signal" or "@Slot") which are just higher order functions to have some syntactic sugar like the QT macros.
There is a proposal (https://github.com/tc39/proposal-signals) for standardized signals. Maybe that's not what you're thinking of. But if it is, there's a polyfill and other prior art (eg, preact-signals -- https://preactjs.com/guide/v10/signals/ -- which are not specific to p/react).
The first thing that comes to mind is that Qt now has a WebAssembly port[1] using Emscripten[2], so depending on your use-case, you could possibly just run Qt on the Web platform and avoid the need for a JavaScript framework entirely.
[1]: https://doc.qt.io/qt-5/wasm.html
[2]: https://emscripten.org
[1]: https://doc.qt.io/qt-5/wasm.html
[2]: https://emscripten.org
Not sure how it works in Qt, but in regular React you'd just use a shared Context that all the components and their children can access. That way you don't have to explicitly pass props and setters and getters back and forth.