Alternative project setup - routing and refreshes

[rogerhutchings]

Soooo I've been thinking about how the site is going to appear to an end user, and it occurs to me that once we have more than one app in place, they're going to see more full page reloads.

The way Next client-side routing works is that it attempts to find a matching route, and if it fails triggers the refresh to allow it to be picked up by a different zone - default behaviour is to no longer show a 404.

We can either not worry about this, or if we do want to maintain the front-end seamless navigation (which I quite like, to be honest), we'd need to configure things slightly differently; we'd could have:

• one 'core' project, which contains all the routing logic, then the page components in that can import their contents from sub-projects.
• sub-projects exporting both routes and components, and the core app importing both (into server.js and pages - there'd still be tight coupling in the pages dir, but I don't think there's an easy way around that)

One downside is that we wouldn't be able to scale parts of the site independently; they'd all have to be scaled up.

Throwing it out there for consideration...

[srallen]

I think we should do a bit of UX research first. If the average user doesn't mind full page refreshes, then we could choose not to care either and not put the dev effort into it. I don't see any benefit about this other than UX.

[rogerhutchings]

Ops would become simpler, as we end up with a single app, both for production and doing things like staging builds

[rogerhutchings]

We'd save some code duplication on common things the user store. I know we're planning to abstract that out anyway, but still.

We'd also save on API requests if so; crossing an app boundary would mean requesting the user details again at the very least

[eatyourgreens]

The overhead of logging in again when you go to the Publications page is quite annoying.

[rogerhutchings]

Ugh, just thought of another one - data use. If we traverse apps, we're going to ask the client to download a lot of the same packages in different bundles, unless we can do something clever with common webpack configs