Mark Bakhit

@rmorshea I can also develop a WSGI variant of this. However, it will only work with WSGI webservers that have official websocket support: `werkzeug`, `gunicorn`, `eventlet`, and `gevent`. The design...

WSGI middleware would grant us compatibility with the following frameworks: https://wsgi.readthedocs.io/en/latest/frameworks.html Unfortunately tornado uses its own custom API, so we would either need to drop support for tornado or keep...

I'm realizing that tornado support should almost certainly be spun off into its own package, similar to ReactPy-Django.

Unfortunately, `async for msg in msgr.consume("my-message-type"):` is fundamentally flawed since it relies on our async `use_effect`. We would need a stateful async paradigm, similar to `Django Channels` consumers.

After today's tag up, two theoretical interfaces could look like this Notes - Use messenger will never restart a consumer that is already running - We should timeout the consumer...

Note: We may want to make some considerations around [Django Channels Layers](https://channels.readthedocs.io/en/stable/topics/channel_layers.html) while developing this interface. It's an existing ASGI messaging paradigm, so taking inspiration from their interface might not...

I don't believe anyone has had time to untangle this issue yet, so feel free to take a stab at it!

The more I develop this, the more I realize it's unwise to finish this PR until the following issues are closed - #1079 - #653 This PR is in a...

@rmorshea I will implement things using `starlette` for static files now, but ideally I don't want a web framework to be a dependency for us. I would feel more comfortable...

Note to self: It seems logical to mandate that ReactPy standalone's root component must be a `html.html` node. By forcing the user to template the whole page, this would eliminate...