Ryan Morshead

This would necessitate a 2.0 release though. It seems like there are other things we might want to break if we're going to do that.

I think I've been going about this from the wrong angle. If implementing the custom JS component interface is going to require that you import some utilities from `@reactpy/client`, we...

This library seems perfect for what we're trying to do: https://github.com/samwillis/nodejs-pypi

As noted in the linked comment, the messaging scheme (as it stands today) only _anticipates_ a message routing system. It would be useful to write up a task for actually...

Yup. I actually completely forgot about that.

> The name `use_channel` kind of implies that multiple channels and/or channel groups can be defined per component I think this is true. One could imagine a server-side component that...

On thinking about this a bit. I actually think the current design is flexible enough to accommodate signals: ```python from weakref import WeakSet from idom.core.hooks import current_hook, COMPONENT_WILL_UNMOUNT_EFFECT class Signal:...

The signal pattern seems preferable to contexts in most cases. Contexts have the benefit of being scoped to a given `ContextProvider` which means that one context can have different values...

The reasoning behind my assertion that signals are better comes down to two factors: 1. No need for a context provider - one less thing you need to learn 2....

More reasons to use signals over standard hooks: https://emnudge.dev/blog/react-hostage#fixing-react I'm realizing that signals could actually be better than the standard `use_state` hook if integrated a bit more into ReactPy's core...