3 ms·
One approach I don’t mind is to just make a HTML file per screen in the application and route like the rest of the web. When you bring in modern things like se
by mdhb 3y ago
One approach I don’t mind is to just make a HTML file per screen in the application and route like the rest of the web.
When you bring in modern things like service workers and the prefetch API you can still very much keep the speed that is traditionally associated with SPAs.
Otherwise I’ve seen good things said about both of these options:
1. https://github.com/vaadin/router https://github.com/vaadin/router
2. https://github.com/lit/lit/tree/main/packages/labs/router https://github.com/lit/lit/tree/main/packages/labs/router
Both follow the mental model of mapping a URL pattern to a component fairly intuitively.
- wg0 3y agoOne file per screen is actually awesome. That's the "MPA" many frameworks are boasting about. The big win here would be that if you have a huge app (let's say an ERP kind of app that has too many screens and dialogs and what not) then that can be easily decomposed into separate pages that are far more manageable. You can easily wrap these pages up as Electron/Tauri app or Capacitor etc for mobile. Deep linking however would be interesting in that if someone pastes a URL, we have to load the exact screen/dialog etc.
- mdhb 3y agoI like to keep a mental model that a page level component uses URL parameters the same way I would write a CLI application reads in arguments. Not at all meaningfully different from say void main(List<String> arguments) { runApp(MyApp(arguments)); }