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).

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.

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