Client-side Routing without hitting the server

Currently, when using Client-Side Routing (see docs here and there), the client-side pageContext is fetched from the server.

Some people want to be able to navigate between pages without hitting the Node.js SSR server. I’m opening a ticket for dicussing this.

I’m willing to implement this but this will require a couple of days work, so don’t expect this too soon.

👍 this ticket if you want this. The more 👍 this ticket collects the more will I increase the importance of this. And better yet, add a comment elaborating why this is crucial for you and I’ll then also increase urgency.

Edit: Most of the time, this is only about (negligible) server cost servings. For most apps, performance and cost implications are negligible. (Note that the static middleware of your Node.js server always needs to be hit anyways in order to get the latest code of the new page. It’s mostly only about reducing Node.js work load.)

[brillout]

addPageContext() has been renamed onBeforeRender() in v0.3.

Alright, so the plan is following:

• You’ll be able to define onBeforeRender() hooks in .page.js files (instead of .page.server.js). Hooks defined in .page.js files are isomorphic: they can be called in Node.js as well as in the browser. When doing Client Routing, they are called in the browser.
• If a page has no onBeforeRender() defined in its _default.page.server.js nor in the page’s .page.server.js then there is no request made to the server.

This means that if you move all your onBeforeRender() hooks from .page.server.js to .page.js then client-side routing will never make a request to your Node.js server.

I’m not sure what should happen if there are two onBeforeRender() hooks defined: one in .page.js and another in .page.server.js. I’ll probably throw a [Wrong Usage] exception until someone found a useful use case for it.

Thoughts?

[brillout]

I’m finishing up the 0.3.0 release. I’ll re-consider this ticket after the release.