Repository navigation
How the frontend components should work #7738
Description
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
Activity
ChristophWurst commentedon Jan 8, 2018
Totally agreed. This is exactly what I had in mind too.
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 commentedon Jan 8, 2018
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 commentedon Jan 8, 2018
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 commentedon Jan 8, 2018
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.
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 commentedon Jan 8, 2018
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.
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 commentedon Jan 8, 2018
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.
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 commentedon Jan 9, 2018
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 commentedon Jan 9, 2018
@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 commentedon Jan 12, 2018
Quick add: how do we integrate this with github? One repo for each component?
Also: two différents example of components
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 commentedon Feb 3, 2018
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 commentedon Feb 4, 2018
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 commentedon Feb 5, 2018
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 :)
15 remaining items
raimund-schluessler commentedon Jul 2, 2018
I would vote for anything but a submodule. I always found submodules a hassle and error prone.
tcitworld commentedon Jul 2, 2018
Individual npm packages should be nice.
skjnldsv commentedon Jul 2, 2018
@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 commentedon Jul 11, 2018
Moving to 15 as this is an ongoing effort.
skjnldsv commentedon Jul 11, 2018
Yes, this is not really relevant to nc versions :)
georgehrke commentedon Jan 4, 2019
bump
skjnldsv commentedon Jan 4, 2019
@georgehrke shall we close now?
georgehrke commentedon Jan 4, 2019
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 commentedon Jan 4, 2019
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 commentedon Jan 4, 2019
Like @juliushaertl said