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.
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.
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.
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.
[dead]
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
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.