Description below leverages the terminology intrinsic to the Model-View-Controller (MVC) pattern.
We propose a unified model that shares signals between backend and frontend through a strongly-typed definition of Signal<T>, part of the HtmlFlow API.
A controller that instantiates a Signal may automatically mount a new route that emits a DataStar patch signal whenever the signal updates, e.g., route /controller-events.
That signal instance can be part of the controller’s state and passed to a HtmlFlow view via, for example: someView.render(signal).
We may provide a new type of view that, whenever it receives a signal as its model, automatically subscribes to the corresponding SSE route. For example: data-init="@get('/controller-events')"
Interaction scheme
Controller
|
| --- new ---> Signal<T>
| |
| | --- mounts ---> SSE Route (/controller-events)
|
v
Browser --- HTTP GET ---> Controller
|
v
View includes data-init="@get('/controller-events')"
Browser --- POST/PUT/... ---> Controller
|
v
Updates Signal
|
v
Emits SSE event /controller-events --- updates ---> Browser View through Datastar
Description below leverages the terminology intrinsic to the Model-View-Controller (MVC) pattern.
We propose a unified model that shares signals between backend and frontend through a strongly-typed definition of
Signal<T>, part of the HtmlFlow API.A controller that instantiates a
Signalmay automatically mount a new route that emits a DataStar patch signal whenever the signal updates, e.g., route/controller-events.That signal instance can be part of the controller’s state and passed to a HtmlFlow view via, for example:
someView.render(signal).We may provide a new type of view that, whenever it receives a signal as its model, automatically subscribes to the corresponding SSE route. For example:
data-init="@get('/controller-events')"Interaction scheme