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
{{ message }}
This repository has been archived by the owner on Feb 19, 2024. It is now read-only.
Overall loading state should look more like the components about to render on the page
Related to above, we should be able to load individual components in their own async bundle using import() and display an appropriately-styled loading state while the bundle is loading.
The preload state should look better as well (before data comes through the primary components endpoint)
The problem:
Irving is intentionally ignorant of routing—it lets your backend handle that. This makes the setup and configuration of the app much, much simpler. However, it does prevent us from knowing what a page will look like before we've loaded data for that page from the endpoint. This means without data we don't know what components will render, and thus don't know what loading placeholder components to display.
Possible solutions:
Improve the current loading state component (used before data returns from the components endpoint). This should probably be done no matter where we end up on the other parts of this issue. The loading state should:
look vaguely like a webpage
perhaps cover the page fully and obscures any oddities during loading
This will allow us to 1) display the global loading component while data is loading -> 2) display component placeholders while async components are loading -> 3) display the fully-rendered page.
Create an additional endpoint in wp-irving responsible for one thing: allowing mapping from path to the associated template. This could be accomplished in a couple ways:
Endpoint returns a series of path regexes that could be used to determine which template will render for which path, depending on which regex matches against a given path.
Endpoint receives a path or array of paths and returns a template or array of templates associated with those paths.
We could potentially leverage redis to make this process faster. There are a lot of redis features we are not making use of currently.
Include a string corresponding to a template component name property in each <Link /> component. This string would be used to determine which template placeholder should render before data/components have finished loading upon clicking that <Link />. This strategy can either be used on its own (with a string manually provided in the component config) and/or used in conjunction with the above wp-irving endpoint.
The text was updated successfully, but these errors were encountered:
There are multiple parts to this issue:
import()
and display an appropriately-styled loading state while the bundle is loading.components
endpoint)The problem:
Irving is intentionally ignorant of routing—it lets your backend handle that. This makes the setup and configuration of the app much, much simpler. However, it does prevent us from knowing what a page will look like before we've loaded data for that page from the endpoint. This means without data we don't know what components will render, and thus don't know what loading placeholder components to display.
Possible solutions:
components
endpoint). This should probably be done no matter where we end up on the other parts of this issue. The loading state should:This will allow us to 1) display the global loading component while data is loading -> 2) display component placeholders while async components are loading -> 3) display the fully-rendered page.
wp-irving
responsible for one thing: allowing mapping from path to the associated template. This could be accomplished in a couple ways:name
property in each<Link />
component. This string would be used to determine which template placeholder should render before data/components have finished loading upon clicking that<Link />
. This strategy can either be used on its own (with a string manually provided in the component config) and/or used in conjunction with the abovewp-irving
endpoint.The text was updated successfully, but these errors were encountered: