Server: [WebFrontend] Allow switching between apps without reloading full page

[simonbuehler]

Steps to reproduce

1. Use music player, play song
2. do some work like change to files app
3. sound gone as full page reload is triggered and Interface is not divided into components

Expected behaviour

Interface should be divided into components so only parts of the page get re-rendered, allowing e.g. to keep a audio player alive during partial page refreshes

Actual behaviour

full page reload

Server configuration

Nextcloud version: (see Nextcloud admin page)
11

hi,

basically it boils down to divide the Interface into components that get partially and independent rendered so its possible to have a Menubar with the apps, a area below where apps could register for space (e.g. audio player bar extendable) and the main area below rendering the selected app content.
Don't know why full page reloads are necessary today, can this be done?

Would like to get some insights for this, thanks

[MorrisJobke]

Don't know why full page reloads are necessary today, can this be done?

Because we are as of now not limited to one specific JS framework. We want to have an as low barrier of entry as possible. That means, that every app can load what ever JS they want to have. We don't dictate any JS framework to the app developers. Also with this approach it is possible to have apps that are a lot longer compatible to a new Nextcloud version. Updating a JS framework is nearly impossible if we would have to wait for all app developers to catch up with the new APIs in this framework and maybe adjusted way to develop against the new version.

I guess this is really out of scope at least for the next year or two until we maybe come up with an idea how to get this working.

Also: why is a full page load bad (except for the music player example)? Usually a page load should be fast enough to be not a problem at all. Yes we are not perfect, but we try to make it faster with every release so that a app change doesn't cause a big delay.

cc @jancborchardt @karlitschek

[karlitschek]

I like the idea as a long term goal of course. The problem is that this would require a rewrite of a lot of the apps. And the even bigger problem is that this would require a lot of coordination between all app developers. And this would limit the number of 3rd party apps a lot and would increase the complexity of writing an Nextcloud app even more. An it would force everyone to use the same framework. Which is tricky if you look at the average lifetime of JS frameworks.

So I agree that this is a long term goal. But probably nothing for the short term.

[simonbuehler]

thanks for the feedback, i see your points as why there is no hard requirement for a specific app design.

Why are page reloads bad? With my fairly average install the switching to the files app loads around 5,8MB of js code in 147 files alone, the calendar wants 62 js files with 5.1mb and without http2 its just not snappy, let alone mobile use.
What about a browser notification in the top bar when the mail client has a new mail even when you are using another app currently? Or with the upcoming video/audio/chat features, a page reload would cancel those interactions and having to use multiple tabs just doesn't feel right in 2017 😜

i guess the challenge is to find the right balance of requirements for apps to fit into the desired (re)loading behavior without limiting them to a specific js framework, hope this will be tackled in the not too far future.

[MorrisJobke]

Why are page reloads bad? With my fairly average install the switching to the files app loads around 5,8MB of js code in 147 files alone, the calendar wants 62 js files with 5.1mb and without http2 its just not snappy, let alone mobile use.

We worked on this really hard to get this number down. We roughly cut requests and size in half already and are steadily improving.

[MorrisJobke]

As this is not a really specific issue I will close it. We try to reach this goal, but in smaller steps.