Pages other than the current page are difficult to access

[OlaviSau]

Description

The page system is the main way to define the routes and there doesn't seem to way to define base routes outside of the filesystem, see issue. This creates a situation where the page is difficult to reuse without moving data outside of the page. Although that is acceptable this disconnects the data (html / component / metadata) from the page and routing. This means that there is no guarantee that the data is actually connected to the route and Vike route information / hooks is difficult to wire together. I don't think this is a major problem, but I think there should be public methods to access page data other than the current page or to be able to register routes programmatically. Programatically defining routes by default solves this issue as then the data can be connected routes in user land and is thus available via normal means. There should be some method to have the route information associated with the page as well.

This can already done by accessing private properties in the context, namely context._pageConfigs. I think there's also some plugins using vike/__internals to access this data. I think these should just be made public and more clearly accessible instead of the current data:
const pageEntry = pageConfig.loadVirtualFilePageEntry().moduleExportsPromise
const page = pageEntry.configValuesSerialized.Page.valueSerialized.exportValues.default

Concrete examples:
User attempts to load an product page, but something in the page goes wrong and cannot be recovered. I would like to be access the error page.
User wants to log in a page that has persistent data, I would like to show the component from the login page in a dialog.

[brillout]

User attempts to load an product page, but something in the page goes wrong and cannot be recovered. I would like to be access the error page.

Why not throw render(statusCode) to render the error page?

User wants to log in a page that has persistent data, I would like to show the component from the login page in a dialog.

Same: why not throw render('/login')?

The more I know about your use concrete use cases, the better.

[OlaviSau]

It would cause a new render and thus would break the example. It would be possible to work around this, but that would be more complicated than using a component outside of the page or using the private methods to get the page.

User wants to log in a page that has persistent data, I would like to show the component from the login page in a dialog.

[OlaviSau]

would break the example.
Wouldn't the entire page be re rendered instead of changing a part of the page?
but that would be more complicated
Options:

1. Store the current state of the page, but I would say that is more complicated than keeping the page as is.
2. Store the component outside of the pages, but then we lose the link to the pages and in our particular case there is a base layer and then an app layer, in this case the app layer defines the route, so we would need to move the component outside of the app layer to use it in the base layer instead.

None of these cases are insurmountable, initially I was just wondering if there's a nice way to replace the usages of private with public API's without moving too many things around. I don't want to make it seem like it is a hard requirement. Though we did investigate the use of throw render() for the error page. Do I understand correctly that throw render only works while the rendering is ongoing and cannot be thrown dynamically later? Example being - a critical part of the data fails to load. I think though that part at least in our code base can be replace with navigate without history change.

[brillout]

About 1, why not use a global store? Since that's the goal of global stores like Redux or Zustand: preserving state across pages. I don't see how using throw render() or directly accessing the error page makes any difference in that regard.

Not sure I understand 2. Not sure what you mean by "base layer". Do you mean you're developing a framework (base layer) and then multiple apps (app layer) that use your framework?

Have you seen the throw render('/login') technique to preserve the current URL as explained at https://vike.dev/auth#login-flow? Doesn't it achieve the same as what you're doing with loadVirtualFilePageEntry()?

[OlaviSau]

Not sure I understand 2. Not sure what you mean by "base layer". Do you mean you're developing a framework (base layer) and then multiple apps (app layer) that use your framework?

Almost, but not exactly correct to call it framework - more in a sense of components / services that are then consumed by several apps.

About 1, why not use a global store? Since that's the goal of global stores like Redux or Zustand: preserving state across pages. I don't see how using throw render() or directly accessing the error page makes any difference in that regard.

It's not really about whether it can be done, because it can and we have a global store. It's more about all the things that then need to change because of that. I didn't originally implement the page logic and admittedly it's not like I particularly like the current implementation. It's more that I don't necessarily see a reason to hide Page data. I also don't want to make it seem like this is some unavoidable feature that we must have, the original question was more along the lines of "Can I replace this private api usage with public api usage?"

Have you seen the throw render('/login') technique to preserve the current URL as explained at https://vike.dev/auth#login-flow? Doesn't it achieve the same as what you're doing with loadVirtualFilePageEntry()?

I have, it's just that it's not exactly the same for several reasons, though I really do think a pseudo nav can work in this case.

[brillout]

Can I replace this private api usage with public api usage?

I'm generally in favor of exposing powerful low-level functionalities. But in this situation I ain't sure it's worth it — note that exposing a clean public API is far from trivial (designing an API to be future-proof takes a significant amount of considerations).

Tha'ts why I'm pushing back a bit on this.

I'm open to it, but I'd need more insights in how it would enable neat things for the user.

Feel free to continue the conversation.

[OlaviSau]

Having a clear, "It's not possible to access pages other than the current page via public API" is also a good answer :) It's possible to design around that, but I will see if there's something we hit that really need it with no workarounds.