All components are currently rendered solely via WebSockets. This is highly convenient for development and state management purposes, however, it limits ReactPy-Django to ASGI applications and cloud hosting services that support WebSocket.
Proposed Actions
Develop a HTTP mode, which will require two things
A separate HTTP client
A separate HTTP backend, which involves reading/writing ReactPy's Layout from the database.
Our Layout must be serialized via dill.pickle. We need to also be able to handle scenarios where deserialization fails (such as when the Layout API has changed), and we fallback to a new layout.
This backend will likely involve adding a layout = models.BinaryField(null=True, blank=True) field to our ComponentSession database model.
We might also want to develop some (optional?) way to automatically fall back to HTTP if WebSocket connections fail.
I'm honestly not sure if there's a way to make use_effect hooks work properly under this paradigm.
Current Situation
All components are currently rendered solely via WebSockets. This is highly convenient for development and state management purposes, however, it limits ReactPy-Django to ASGI applications and cloud hosting services that support WebSocket.
Proposed Actions
Develop a HTTP mode, which will require two things
Layout
from the database.Layout
must be serialized viadill.pickle
. We need to also be able to handle scenarios where deserialization fails (such as when theLayout
API has changed), and we fallback to a new layout.layout = models.BinaryField(null=True, blank=True)
field to ourComponentSession
database model.We might also want to develop some (optional?) way to automatically fall back to HTTP if WebSocket connections fail.
I'm honestly not sure if there's a way to make
use_effect
hooks work properly under this paradigm.