Repository navigation
[Meta] Contribute generic components from @conduction/nextcloud-vue for the Tables app (NcTable, NcPagination, NcTabs, …) #9126
Description
Is your feature request related to a problem? Please describe.
We as Conduction are currently working with Nextcloud on the Tables app. For that, we want to add some more components that we use ourselves from our own library @conduction/nextcloud-vue, as we discussed in Berlin. We would like to contribute them here, so that they can be reused.
The designs are based on the Nextcloud components. For example, the pagination component uses NcButton, and the tabs use Nextcloud's CSS styling and look like the tabs of the right sidebar.
Describe the solution you'd like
We'd like to contribute them as generic components, without anything Conduction-specific. Each one is ready with styleguide docs and tests.
New components:
- NcPagination: page buttons with ellipses, page size selector, pages as links
- NcTable: the Files app table as a component: sorting, row selection, row actions, loading and empty states
- NcPageHeader: heading with icon, description and actions at the top of a page
- NcStatsBlock: a single statistic for a dashboard
- NcTabs: tabs in the app content, styled like the sidebar tabs
- NcCard: a card for grids of items, optionally one big link
- NcQuickFilterBar: a row of filter pills above a list
- NcLockIndicator and NcLockedBanner: show that an item is locked, and by whom
Extensions:
- NcChip: a small size, an info variant and a light style, for status labels
- NcBreadcrumbs: pass the crumbs as data instead of as child components
Every component also has optional CSS custom properties based on the format of the NL Design System tokens, so government organisations can apply their own house style. They're not set by default, so nothing changes visually. They're in separate commits, so we can also move them to separate PRs.
Describe alternatives you've considered
NcAppSidebarTabonly works in the sidebar, so there is nothing for tabs in the app content.- A status label is just a smaller chip, so we extended
NcChipinstead of adding a new component. - Keeping everything in our own library works for us, but not for other apps.
Additional context
We'll open one PR per component (the two lock components together), a few at a time, each linking back here. We start with NcPagination, NcTable and NcChip, together with a small fix for the styleguide: Markdown tables in the docs currently break the props tables below them, and all three PRs document their CSS variables in such a table. A second small fix, for a pending update left behind in useFormatRelativeTime, will follow later. The other components follow after that.
Some questions about this approach:
- Do you want these, or are there any you'd rather not have?
- Does one PR per component work for you?
- Should the NL Design System properties stay in, or go to separate PRs?
- Are the names okay?
- Do you want the NcChip and NcBreadcrumbs changes backported to
stable8, or ismainenough?
Activity
ShGKme commentedon Oct 27, 2026
Yes, 1 PR per component is the best to keep discussion isolated. And with 1 PR per component, one can be merged while another is still on discussion or blocked.
ShGKme commentedon Oct 27, 2026
Yes, currently we keep
stable8andmainin sync in features and bug fixes until we stop supporting Vue 2 (hopefully very soon).Exceptions are bundle/tooling related changes and internal refactoring.
ShGKme commentedon Oct 27, 2026
In general,
@nextcloud/vueshould not depend on NL Design System properties.The question is: should components have many CSS variable params for overrides and/or customizations.
IMO, there are 2 different cases.
First - customization.
For example, we have a button with 4 variants. But there is a specific place in an app where a button must have a different, custom color. Having a CSS variable param instead of deep styles overrides definitely makes sense. But keeping in mind, that then more customization options we introduce, then more we promise to maintain.
Also, IMO we don't need a CSS variable param to override something that is already inherited CSS property. For example, to make a specific button
text-transform: capitalize, we don't need a param. We can use a general CSS property that this button inherits.Second - theming.
For example,
--chip-error-color. Here the use-case isn't clear for me. Fonts, named (themed) colors, spacing -- all of it comes from Nextcloud Theming and should be consistent across different apps on Nextcloud instance or a page.primarycolor should be different on different parts of the page. An app should never havefont-family: serifwhile entire pagesans-serifand etc.Large amount of such params providing detailed theming fine-tuning is hard to maintain.
We need to make sure that after refactoring or extending a component, all of them still have the same effect.
For instance, we had several Tabs design changes (example). Between different designs meaning of "tab's background" or effect of properties change can be very different.
With Nextcloud theming we also making sure that the colors are accessible with different theming configurations.
Additionally, CSS variables (unlike component names, props, evens) live in a global scope.
If we introduce
--table-background-color, the name is blocked page-wise for all concurrently supported versions.ShGKme commentedon Oct 27, 2026
I'll respond per component below for simplicity. And the next comments will be mostly my opinion, other developers and/or designers may have different opinion.
ShGKme commentedon Oct 27, 2026
NcPagination
Makes sense. As with every new component, good to coordinate with @nextcloud-libraries/designers
ShGKme commentedon Oct 27, 2026
NcTable
This is a complex one. It makes sense. On the other hand, tables are one of the most complicated UI component when implemented with:
I'd say, let's see if we can split it into more generic UI components and more powerful data tables.
ShGKme commentedon Oct 27, 2026
NcPageHeader
Currently I don't see how it can be applied in apps with this design.
It might makes sense to have something like
NcAppHeader, which would be inline with navigation and sidebar, preserve space for toggle buttons etc. But theNcPageHeaderdoesn't fit it.ShGKme commentedon Oct 27, 2026
NcStatsBlock
I'm unsure it is something useful for general apps and would ask for @nextcloud-libraries/designers opinion.
ShGKme commentedon Oct 27, 2026
NcTabs
Definitely a missing component.
Though it isn't as complicated as tables, I'd still see if we can split it into a base component and more specific component (that we already have for
NcAppSidebartabs internally).NcTabssounds very generic, and it would be unfortune if it only supports sidebar style tabs, and we need a new component that will be more generic but with more complex name.ShGKme commentedon Oct 27, 2026
NcCard
I think, it makes sense as a generic UI container, like a paper/pane. A purely UI block with title, content, maybe actions. But in https://nextcloud-vue.conduction.nl/docs/components/cn-card/ it is not very generic:
statsprops that are very specific for stats cards, not a generic containerI'd consider splitting it into a pure generic container and more specific Conduction app component which is Conduction data driven with additional props and modes like stats.
ShGKme commentedon Oct 27, 2026
NcQuickFilterBar
It is a data-driven form generator, but specifically for search.
I'm unsure it makes sense before we have designed generated forms.
ShGKme commentedon Oct 27, 2026
NcBreadcrumbs: pass the crumbs as data instead of as child componentsIn my opinion - yes, but the best to coordinate with the Files team (cc @skjnldsv @susnux)
remko48 commentedon Oct 27, 2026
Alright thanks!
I will respond tomorrow with more detail.
The short answer is that we will remove the CSS variables (NL Design System) from all PRs.
susnux commentedon Oct 27, 2026
Agree!
remko48 commentedon Oct 29, 2026
Backport to
stable8We will make sure that we backport the NcChip and NcBreadcrumbs changes to stable8. Should the new components be backported as well, or not?
CSS variables
I have removed all the CSS variables from #9127, #9128 and #9129. These were meant for theming, but are now removed so the components only use the Nextcloud styling.
NcPagination (#9127)
Alright, thanks! We will wait for the designers' input.
NcTable (#9128)
For a better picture of what is in the PR: NcTable only displays the rows it gets. It doesn't sort, filter, paginate or load data itself. A sortable header only emits which column was clicked, so the app can sort or fetch the rows itself to pass them back to the table. It also renders every row it gets, so there is no virtual scrolling.
What it does:
width,alignand an optionaldescription,cell-<key>slots, arowActionscolumn, loading and empty states, and a required (hidden)captionaria-sort, bound withv-model:sortv-model:selected; each checkbox is labelled with the name of its rowrowClickevent for mouse users that ignores clicks on controls and text selectionsIf you think this is too much for one component, we could:
NcRadioGroup/NcRadioGroupButtonshare their state.NcTablekeeps the caption, scroll, styling and the sort and selection state, and the app writes its own rows and cells.Which do you prefer?
NcPageHeader
We had added the NcPageHeader component, but after some further research we found that the Tables app does not actually use it. So we suggest not opening a PR for it, unless you would like a component for an app header.
NcStatsBlock
Thanks, we will wait for the designers' opinion.
NcTabs
Agreed. The name
NcTabsshould then go to the generic base, and the sidebar style becomes one of its variants, so we don't end up needing a new component with a longer name later.Our NcTabs only has one style at the moment: the sidebar style, with an icon above the label and an optional counter, the same as the
NcAppSidebartabs.In our apps we also use two other tab styles, which are now built separately in the apps themselves:
We would suggest one
NcTabsbase that handles the tablist behaviour (v-model, arrow keys, roving tabindex,aria-controls, etc.) with avariantprop for these three styles, andNcAppSidebarcould then use it internally with the sidebar variant. The alternative is a base component with separate styled components on top of it.Would you prefer a
variantprop, or separate components?NcCard
The CnCard in our docs is our own component with stats. The NcCard we want to contribute is already a generic container without stats: a title, a description, an optional icon, a slot for the content, actions and a footer, and optionally one big link.
NcQuickFilterBar
Makes sense, we will wait until generated forms are designed.
NcBreadcrumbs
Great, then we will make the PR soon.
NcLockedBanner and NcLockIndicator
You didn't mention these yet. Do you have an opinion on them?
Antreesy commentedon Oct 30, 2026
First one is almost identical to NcNoteCard, apart from missing 'locked/grey' theme variant, and dedicated actions slot. Maybe we can extend the existing component instead?