Router Service (WORK IN PROGRESS)

[amcgee]

This is a placeholder for an intra-app (and possibly inter-app) Router Service specification, including both app-runtime and app-adapter components

[amcgee]

Inspirations : https://nextjs.org/docs/basic-features/pages#pages-with-dynamic-routes

[ismay]

To me the strength of next.js' approach is the convention over configuration aspect. I've found it nice to work with. Though, I do wonder how far we'd get as we don't have a node server taking care of all the backend logic that next.js allows you to use. So for static routes I can see how we'd implement that, and it seems like a nice paradigm. Dynamic routes though I don't really see in our context just yet.

[amcgee]

@ismay can you expand on how you don't see dynamic routes in our context yet? Dynamic routes like /pages/visualizations/[id].js actually only works client-side in next (unless you generate the set of valid routes server-side), and I think they would actually be one of the most powerful features we'd want in a page-based routing system so that we could support wildcard id routes for an individual user, program, etc. - maybe I'm misunderstanding what you mean by dynamic routes though?

All that being said, a lot of the power (and particularly the client-side performance) of next comes from SSR and static generation - eventually we'll probably support both, but we could target (1) client-side routing only, (2) static generation / pre-hydration for known routes, and (3) SSR in that order, I think

[amcgee]

One big question for me is - should we try to rework the platform build pipeline to actually use nextjs under the hood, or should we just take some of the good pieces and build them ourselves? I have concerns about both approaches, but I really do think the convention-over-configuration nextjs dev experience (@ismay agree it's one of the biggest strengths) is quite akin to what we aim to provide with our platform.

[ismay]

can you expand on how you don't see dynamic routes in our context yet? Dynamic routes like /pages/visualizations/[id].js actually only works client-side in next (unless you generate the set of valid routes server-side), and I think they would actually be one of the most powerful features we'd want in a page-based routing system so that we could support wildcard id routes for an individual user, program, etc. - maybe I'm misunderstanding what you mean by dynamic routes though?

Yes I think we're talking about the same thing. I'm just used to the static paths/props generation with next.js, hadn't even come across the query object that the router provides. Ok, so I guess that then the only missing piece if we were to integrate something like this, is build logic that takes the filename, and converts it to parameters that are made available to the page component.

All that being said, a lot of the power (and particularly the client-side performance) of next comes from SSR and static generation - eventually we'll probably support both, but we could target (1) client-side routing only, (2) static generation / pre-hydration for known routes, and (3) SSR in that order, I think

That would be great. Though that would mean that we need a backend that's able to handle the server-side component. I wonder how doable that is for us?

One big question for me is - should we try to rework the platform build pipeline to actually use nextjs under the hood, or should we just take some of the good pieces and build them ourselves? I have concerns about both approaches, but I really do think the convention-over-configuration nextjs dev experience (@ismay agree it's one of the biggest strengths) is quite akin to what we aim to provide with our platform.

I would prefer to use next.js directly, if we feel their approach fits our usecase. I think it forces us to standardize, which I think is good. Plus, I don't think we have the manpower to reach anything near the level of quality that this lib provides. Yes, we might lose some customizability, but to me that's a good thing in the end. Anything custom requires manpower to do well, and I think that as an org. the functionality that next.js provides probably isn't where we want to add value.

[Mohammer5]

Should've read this before I wrote my comment.. Using next.js would be nice imo!

[amcgee]

@mediremi raised this again in #251 - copying here:

---

A common design pattern in our apps is using a grid layout with a sidebar containing navigation menu items on the left and the app content on the right. This pattern is often paired with react-router-dom and its HashRouter component to provide SPA routing.

Issues with current way of doing things

• Lack of consistency (both code and UI)
  • UI
    • Inconsistent sidebar and app content backgrounds
    • Inconsistent gutters
    • Inconsistent app content padding
    • Making menu items keyboard accessible would mean updating the version of @dhis2/ui for every app
  • Code
    • Different ways to organise + config vs code approach
• External app developers may not be aware of this design pattern, so may use their own components
• Forced to use HashRouter as backend does not know each app's routes

Proposed solution

d2.config.js could be used by developers to declare the routes used by their app like so:

const config = {
    // ...
    pages: {
        '/': 'src/pages/App.js',
        '/some_page/:id': 'src/pages/SomePage.js',
        // Route that shoud not visible in sidebar
        '/some_other_page': { component: 'src/pages/SomePage.js', sidebar: false }
    }
}
module.exports = config

and this config would then be used by the app shell to construct a sidebar and router. The runtime would reexport the Link and history exports from the routing package for consumption by the app. Declaring the routes in this way also allows the backend to build a global routing table and hence we would not need to use hash routers.

If config.pages is not present then the app shell would not create a sidebar and allow the app developer to manage routing.

[Mohammer5]

Btw, I'm working on the SMS Config app, I applied the structure that I've explained above: dhis2/sms-configuration-app#253

Just to clarify: @ismay and I are just experimenting with what we'd like more and I went for the approach highlighted above. If we think that it's too much work / nesting, I'm totally open to changing it. But so far I like it quite happy with it as it allows to reduce abstractions, it's very clear where to put what and it's been extremely easy to refactor things once the structure has been set up.

[ismay]

I'm not too sure about the distinction between pages and views. I think that's a bit too much. I know I argued for pages being a place where you can have page specific code, but if we're following next.js' architecture, I think we should automate generating routes from all files in pages, and just allow the rest to be in components.

Having a separate views folder is a bit confusing to me in a react app where MVC isn't necessarily stricly enforced. To me, it could be argued that they're all views (pages and components), and that the distinction is based on their function: pages render pages, components are reusable pieces of pages. Adding views adds another category that doesn't fit the functional organisation in my opinion, and seems more related to a different concept. Ember was way closer to the MVC concept when I worked with it, with models views and controllers. For react I don't think I'd prefer using the MVC paradigm as directly when structuring the app.

[ismay]

To me it always feels like react components are more a vertical slice of the MVC pattern (as in, by concern or function), as opposed to being organized horizontally (by technology, as in: model, view or controller).

[amcgee]

+1

[Mohammer5]

Related: #248 (comment)

[Mohammer5]

I thought about this a bit more yesterday. I think we have the following issues if we want to provide a router service:

We need some kind of configuration so the service know about the routes

file structure

This makes it a bit more complicated with co-locating page-related and requires introduce a parallel structure (as I've mentioned in my previous comment). If one of our components wants to link to a route, we can't use a constant that holds the route's path and is the single source of truth for that path, which could make changing routes more complicated (although changing routes rarely happens).

Config file

Can be read by the service easily and it's declarative, but it sounds like it's almost as much work as just specifying the router in the app. Also it'll make it slightly more difficult to change certain things based on which path is active (e. g. displaying the sidebar or not) as we're decoupling the view from the to-be-mounted components.

Config inside source code (e. g. src/routes.js)

Same disadvantages as the config file

---

To me it seems this might make things more complicated than they actually help. If we just say that we routes should not be set up through (potentially dynamic) config files but instead through components as well as that all apps have to use the react-router-dom and its hash browser, and focus on having layout components and style consistency across apps, we'll achieve that all apps look and feel the same and getting into the routes is not really a biggie as you just have to read through the router component that the app implements .

Wrapping react-router-dom or creating our own service seems like it's either an unnecessary abstraction (as we either have to expose the whole api surface of react-router-dom or restrict the custom service's api) or we'll end up implementing a router service which is just re-inventing the wheel.

UI inconsistencies is something we might want as apps might have different requirements / a different target audience, so having the freedom of choosing is nice. The only thing I think we should disallow is having a config for the routes but use the same approach in all apps (component based routing instead of config based routing that dynamically mounts the route components)

[Mohammer5]

If we want to offer SSR, then this is a whole different issue though..

[HendrikThePendric]

A common design pattern in our apps is using a grid layout with a sidebar containing navigation menu items on the left and the app content on the right. This pattern is often paired with react-router-dom and its HashRouter component to provide SPA routing.

I agree this is a very common pattern and some form of standardisation / automation would be good. Personally I would probably just prefer to implement some components that facilitate this common layout pattern instead of introducing a more rigid configuration based service.