You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 into go_chart().
On a normal page request, all go() and go_*() 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:
#[MultiPass("main .data>.chart")]
functiongo_chart(Element$element):void {
// Now $element is already selected from the document.
}
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 automated fetch() 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:
To 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.
It would be really useful to document which go and do functions have executed, and in what order. As part of this issue, the execution order should be sent within a header to the client. Something like X-WebEngine-Logic-Order: App\Page\Index::do_submit;App\Page\_Common::go
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: