-
-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automate multi-pass rendering #635
Comments
A note on throbbersTo avoid "throbbers", previous MPR sections can be cached in the service worker, live-updated when available. This technique was popularised by Instagram back in the day. Really effective was of enhancing user experience and making apps snap. |
A note on PhpGt/ServiceContainer#140It would be really useful to document which |
By default, all page functionality should be put into
go()
However, make it so any
go_*()
function will be called, allowing for functionality to be split into separate functions.For example, on a page where there's basic functionality, and then a chart is rendered, put all the required functionality in
go()
as usual, but move the chart rendering intogo_chart()
.On a normal page request, all
go()
andgo_*()
functions are executed (in any order, technically allowing for concurrent execution).The fancy functionality comes from tagging a go function with a
#[MultiPass()]
attribute.The
go_chart()
function can be tagged with a CSS selector to the element it is isolated to:The fancy stuff can be done by now only executing the main
go()
function on the first render, and each individual Multi-Pass element being updated with an automatedfetch()
request from the client side.Fetch request with "x-go: chart" header to only render that one function (to do multi pass rendering)
There can be more fancy stuff automated by specifying update regularity, so a page can be kept up to date, like
#[MultiPass("main .data>.chart", 3)] // update every 3 seconds
.Maybe web services can be added for #450 , but the main priority is to respect the request-response lifecycle, so WebEngine apps can still be completely used within a terminal browser.
The text was updated successfully, but these errors were encountered: