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?

[georgehrke]

While sharing the enthusiasm for Vue.js, I wouldn't like to see us require developers to use it. The JS world is moving forward so quickly and we can't predict what's gonna happen in the future.

Just two or three years ago, Angular 1 was the future and nowadays it's barely getting any maintenance updates. Who guarantees us that Vue is still gonna be around in 3 or 4 years?

Therefore I would opt for maintaining the (S)CSS / JavaScript package along with a set of well documented plain HTML templates strictly separated from the predefined Vue components. While the Vue components are gonna depend on the former one, the (S)CSS / JavaScript package shall never require the developer to use one specific JavaScript framework. This is not only for the sake of giving app developers the freedom to use the technology they want, but also for our own sake, so we don't become insane having to rewrite the (S)CSS / JavaScript package every 2 years for every new hip JavaScript library that's suddenly replacing everything else.

[skjnldsv]

Just two or three years ago, Angular 1 was the future and nowadays it's barely getting any maintenance updates. Who guarantees us that Vue is still gonna be around in 3 or 4 years?

Angular has been controversial from the beginning. Vue too, but the reactivity and quick migration of every dev on it quickly made things get serious. I see your point but I have trouble setting my mind on this. 😕

As I see it, we should create a similar system as apps. A folder where we could have every component of nextcloud in separate folders. Therefore, we could edit easily every part of the components without changing the others.
The question I have tough, is how could we provide an api/access for those components. If someone is creating a vuejs app, it's easy to import the directive and everything will automatically perform like we want to. But like @georgehrke said, if we don't want to force devs to use a specific language, how could we provide such an open 'mechanism'?

[georgehrke]

Don't get me wrong, I didnt mean to disapprove anything vue.js ;)
I would still like to see us provide vue.js components and I'm looking forward to using them in the calendar app.

We just have to be sure that we don't provide anything exclusively for vue.js and that we also keep well maintained plain javascript APIs :)

[skjnldsv]

I completely agree with you, but how can a vuejs component be used in a non vuejs app for example?

[georgehrke]

but how can a vuejs component be used in a non vuejs app for example?

Not at all, that's why we have provide both: vue components but also well-documented plain HTML building blocks

---

To come back to the original topic :)

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.

Should we make this a breaking change or require apps to opt-in by using a special info.xml flag like <ships-core-assets />?

EDIT: we could also make the transition slowly by:

• opt-in using <ships-core-assets /> in Nextcloud 14
• opt-out using <requires-core-assets /> in Nextcloud 15
• have a breaking change with Nextcloud 16

Then we don't need to provide jQuery

Big 👍, but what about our .avatar() and .contactsmenu() plugins?

[skjnldsv]

Big 👍 , but what about our .avatar() and .contactsmenu() 4 plugins?

I guess we can rewrite them as well? :)

[georgehrke]

I guess we can rewrite them as well? :)

Possible, but they are jQuery plugins and rewriting them without jquery would inevitably break all current usages of these plugins. ;)

[juliusknorr]

jQuery is also used in almost any core app and settings, so in don't think we can get rid of it in the near future.

[georgehrke]

Well, the big incentive here is that were are currently shipping an end of live jQuery 2 that was manually patched by us to fix security issues. And that's painful for everyone, because app-developers have to use ancient jQuery versions and we have to manually keep fixing security issues.

edit: we should at very least isolate the jquery version used by core apps / settings from all the other apps, so they have to ship jquery on their own

[skjnldsv]

@juliushaertl we should at least try our best to plan this removal!

[juliusknorr]

@skjnldsv Sure, just mentioned that so we keep it in mind 😉

EDIT: we could also make the transition slowly by:
opt-in using in Nextcloud 14
opt-out using in Nextcloud 15
have a breaking change with Nextcloud 16

we should at very least isolate the jquery version used by core apps / settings from all the other apps, so they have to ship jquery on their own

I like that idea. As a first step we should then get rid of any jquery usage that is included by default, like the app menu. So when an app renders a basic TemplateResponse with the main template, it can opt out of the shipped jquery.

[skjnldsv]

A bit of talk we had tonight with @georgehrke and @Henni :)

The components should only be a shortcut to a html + css template and of course, if needed, some js.
I already started to work a lot on the standardisation since 6-8 months and I already simplified the different parts of the templates we're using on nextcloud. I don't think we need to change things.

You can find the summary here: #8374

We also need to keep the old fashion way active. If someone want to create an app without js, he must be able to. So, e.g , if someone want to create an appnavigation menu, he has two options:

• Use the documentation and build his template himself
• Use our component

As I see it it would be as simple (for the navigation example) as passing a multi-dimensional array containing all the menu entries trough the component in vuejs.

[juliusknorr]

I created an issue for the opt-out of shipped js libs to track what components are needed for all apps that should probably be moved away from jquery to plain js: #8425

[skjnldsv]

Hey!
How should we version our components?
Should we publish them on a dedicated repo? On nextcloud?

[MorrisJobke]

Should we publish them on a dedicated repo? On nextcloud?

I would say so.

[georgehrke]

@skjnldsv Are there already common components that we could publish in https://github.com/nextcloud/vue-components?

And: Are we gonna publish it as a npm package or just make people submodule the git into their repo?

[raimund-schluessler]

And: Are we gonna publish it as a npm package or just make people submodule the git into their repo?

I would vote for anything but a submodule. I always found submodules a hassle and error prone.

[tcitworld]

Individual npm packages should be nice.

[skjnldsv]

@georgehrke I went for lerna wich is a multi component manager.
You can read this article: https://hackernoon.com/one-vs-many-why-we-moved-from-multiple-git-repos-to-a-monorepo-and-how-we-set-it-up-f4abb0cfe469

All packages will be individual but in the same repo.
I have already started setting things up, but did not pushed yet.

The idea is to have individual published npm packages in a single location for maintainability

[MorrisJobke]

Moving to 15 as this is an ongoing effort.

[skjnldsv]

Yes, this is not really relevant to nc versions :)

[georgehrke]

bump

[skjnldsv]

@georgehrke shall we close now?

[georgehrke]

Well, we have the vue components, but they don't ship styles yet.

Plus we still have the problem of apps relying on js-libs shipped by the server like jQuery, instead of shipping all their dependencies on their own.

[juliusknorr]

I'd say we can close this anyway. It was more about getting our thought sorted here. For the actually movement, we should have separate issues for the apps. For styles we already have some Vue components that ship scoped styles, so it is an ongoing process in the components repo.

[MorrisJobke]

Like @juliushaertl said