Skip to content
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

Open
g105b opened this issue May 25, 2023 · 2 comments
Open

Automate multi-pass rendering #635

g105b opened this issue May 25, 2023 · 2 comments
Labels
Projects
Milestone

Comments

@g105b
Copy link
Member

g105b commented May 25, 2023

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")]
function go_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.

@g105b g105b added the feature label May 25, 2023
@g105b g105b added this to Backlog in Overview via automation May 25, 2023
@g105b g105b added this to the v4 milestone May 25, 2023
@g105b
Copy link
Member Author

g105b commented May 25, 2023

A note on throbbers

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.

@g105b
Copy link
Member Author

g105b commented Oct 25, 2023

A note on PhpGt/ServiceContainer#140

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Overview
Backlog
Development

No branches or pull requests

1 participant