How the frontend components should work

[MorrisJobke]

Hey @nextcloud/designers ,

we talked about this at the conference. I just had some thinking about our whole UI and what a mess it is nowadays to keep all the apps up to date. Maybe we need to rethink how apps work, because we get more and more incompatibilities in the frontend as well as stuff that holds us back.

My idea here was to maybe provide a set of building blocks, that are not shipped within Nextcloud itself, but within the app via NPM/yarn/whatever modules, that the app itself need to ship. Then we don't need to provide jQuery or styles for Nextcloud 13 and 12 and check all the apps, but the apps itself will update the underlying library and has a determined behaviour. If some app developer wants the latest look and feel, the library needs to be updated. Then it's more in the control of the app developer and untangled from the server itself. Also we would reduce the inter app dependencies.

The disadvantage of this is, that the styles are shipped for each app, but on the other side: most apps have them anyways, because they backport it themselves to also have the same nice features in older Nextcloud versions.

Opinions on this? cc @ChristophWurst @jancborchardt @skjnldsv @juliushaertl because I have seen https://github.com/ChristophWurst/nextcloud_vue

[ChristophWurst]

My idea here was to maybe provide a set of building blocks, that are not shipped within Nextcloud itself, but within the app via NPM/yarn/whatever modules, that the app itself need to ship.

Totally agreed. This is exactly what I had in mind too.

The disadvantage of this is, that the styles are shipped for each app, but on the other side: most apps have them anyways, because they backport it themselves to also have the same nice features in older Nextcloud versions.

I don't think everythink has to be shipped by the apps. A base set of CSS rules should remain in the server. Also, we have to have some kind of migration/deprecation path. Thus, making it hard to really remove that from the server.

[jancborchardt]

A big disadvantage though is that the app styles are not consistent across apps. For example the Notes app could just use a way older version of the package than, say, the Mail app.

It’s good that we ship the styles with core, and I think the problem mainly comes from that we first needed to actually standardize it with reusable classes, which is being done more and more. The navigation is finished for example, and so is the app-content-list for Mail and Contacts.

The proposal seems to be marginally better for developers, but has a drawback for users.

Or am I missing something here? cc @nextcloud/designers

[raimund-schluessler]

Well, if the CSS is shipped with server and a change from lets say NC12 to 13 breaks an app and requires adjustements, it is also bad for the user. He cannot use the respective app until the developer fixes it.

So, if we ship CSS with server, an app might not be usable at all, until it is fixed.
If it is shipped with the app, it can still be used, but might look "older", until it is updated.

I would prefer having a defined set of styles included in the app itself and not having to fear the next server release will break everything. Then I could decide to update the CSS when I have time for it and still have a working (possibly old looking) app.

[MorrisJobke]

So, if we ship CSS with server, an app might not be usable at all, until it is fixed.
If it is shipped with the app, it can still be used, but might look "older", until it is updated.

Exactly. That was also the idea here.

Also it is super hard to define proper interfaces in JS that can kept stable. If the app developer actively needs to update then the app developer also can fix it. If the user updates the underlying system (Nextcloud 12 to 13 in this case) the app developer isn't even involved in this process.

I would also prefer the slightly outdated UI in terms of overall usability.

It’s good that we ship the styles with core, and I think the problem mainly comes from that we first needed to actually standardize it with reusable classes, which is being done more and more.

The problem then is, that an external factor updates in case something breaking is involved. We had multiple PRs against a handful of other repos to align them with the updates styles. There wasn't even a chance for transition. And this makes it quite hard to develop stable apps from an UI perspective.

[juliusknorr]

I would prefer having a defined set of styles included in the app itself and not having to fear the next server release will break everything. Then I could decide to update the CSS when I have time for it and still have a working (possibly old looking) app.

That would also be my preferred way. The changes in 13 caused that many issues that made apps partly unusable and required touching almost every app.

It’s good that we ship the styles with core, and I think the problem mainly comes from that we first needed to actually standardize it with reusable classes, which is being done more and more. The navigation is finished for example, and so is the app-content-list for Mail and Contacts.

Well, it is standardized for now. Although if the designed structure is pretty solid, any change that might come to that in the future will cause problems again.

[skjnldsv]

I agree with shipping the css also! It's far easier!
Tough we should tend to unify our modules versions across apps for a same nc version.

Nonetheless, if we use the scss compiling system, we should have the server serve the same css file accross apps that use the same module version. We don't want to cache xxxxx versions of the same css.

It’s good that we ship the styles with core, and I think the problem mainly comes from that we first needed to actually standardize it with reusable classes, which is being done more and more. The navigation is finished for example, and so is the app-content-list for Mail and Contacts.

Well, it is standardized for now. Although if the designed structure is pretty solid, any change that might come to that in the future will cause problems again.

And since the standard is not going to change drastically, we should not have differences (at least major ones) amongst our apps. It will just evolve with the modules!

If we speak about the tech we shall use, where are we heading? Do we want to go for vuejs like we discussed?

[jancborchardt]

Yeah, good points! :) I agree now it's better to have the apps ship the CSS.

@skjnldsv as far as I understand, there has been kind of agreement on Vue.js and experiments are being done in different apps to move to it. Right folks?

[skjnldsv]

@jancborchardt Yes, we already worked on a few stuff to see what we can do and we decided to go for it.
The first biggest work will be the new dav lib, once it's done, we should be clear to rewrite the contacts and calendar apps.

That being said, I already use vue for various web projects since we discussed, to see what we can do and practice. If you're potivated, please do as well! It's very fun :D

[skjnldsv]

Quick add: how do we integrate this with github? One repo for each component?

Also: two différents example of components

• https://vuejsdevelopers.com/2017/10/23/vue-js-tree-menu-recursive-components/
• https://sebastiandedeyne.com/posts/2017/exposing-multiple-vue-components-as-a-plugin

Which way do you prefer? Only adding the component or directly passing js objects to it?

I gladely prefer the second one, more versatility and all the vue compiling is done on the component side and not on the main project.

This rise the question of compatibility tough. Can someone without a vuejs app use our vue components somehow?