[Feedback] My few cents about the current state of the component library

[Michel (cyl3x)]

I have now used the component library several times to build various apps and would like to share my opinions, ideas and thoughts about it.
My feedback is based on my own experience of building Vue applications using external libraries such as NaiveUI, Vuetify and internal ones.

Note that the following is purely my opinion, and while I use phrases like "should", all points are open to discussion.

To give this a bit of structure, I would like to start with the criteria on which my feedback is based:

Modularity

A library's components should be self-contained to allow for optimal bundle size.

Flexibility

A library's components should not feel constrained in their capabilities. Being too fixed could lead to self-developing components, resulting in higher maintenance and less consistent styles.
Therefore, a component should make use of slots to cover most use cases, and also ensure that HTML elements and customisations are left in the template block, rather than being defined alongside your data.

Uniformity of API / prop naming

Props, along with slots, are the way to interact with components. Having a consistent way of naming props greatly improves the learning curve, usability and developer experience of the library.
Many components have a mixture of disable-/enable- and hide-/show- props. Often these are used to indicate what the default value of that prop is, e.g. disable- if it's enabled by default. Default values can/will change, and I would prefer to have a consistent prop naming convention instead.
Looking through the existing components, I would like to point out the following criteria:

• use model-value wherever the state of a component is managed by one value
• use variant to change the appearance of a component
• use size to change the size of a component
• use show prefix to show/hide something visually
• use enable prefix or adjectives (..able) to enable/disable a feature of the component. Ideally, only one pattern is used
• use update:<prop-name> to update prop values to properly match Vue's intentions, Dev's general expectations, and to allow the use of v-model and it's modifiers
• slots that replace props should be named after the prop or have a uniform prefix, e.g. custom.

Data/Form components

• common props: model-value, label, name, error, disabled, help-text, required, etc.

Feedback about the components

mt-banner

• prop hide-icon should be show-icon
• slot custom-icon should be icon

mt-progress-bar

• prop description of progress-label-type says "percentage" instead of "percent"

mt-checkbox

• prop checked should be model-value

mt-select

• prop hide-clearable-button should be show-clearable-button
• prop small should be size and properly not a boolean
• upon open, the list is not included in the components height -> in an iframe that's too small, the list will not be visiable

This component has some performance overhead on large static datasets (> 1000, depending on your system), as each option is prepended in Vue's virtual DOM. Perhaps something like Vuetify's v-lazy might be interesting to implement.

mt-textarea

• if max-length is set, the character counter is not changing on change but blur

mt-card

• prop large should be size and properly not a boolean

mt-empty-state

• is missing slots like buttons, headline and description
• unlike the well worked out mt-card, title and subtitle are named headline and description

mt-tabs

• prop small should be size and properly not a boolean
• has no model-value nor a update:model-value event but instead default-item and new-item-active

mt-modal

• maybe should make use of Vue's <Teleport>
• unlike the well worked out mt-card, this component is rather limited and could make great use of additional slots like avatar, header-right/title-before
• prop width should be named size

mt-popover

• prop disable-flow should be enable-float or floatable
• has a update:is-opened event but no is-opened prop

mt-paginiation

• debouncing the current page would be lovely

mt-data-table

A data table is properly the hardest to be done nicely in a component library. The current implementation is almost well done. One thing that pops right out is that it's not capable of managing any state by its own. By default, the search bar and settings pop over are enabled, but both aren't functional as long as no prop is bound.

• disable-settings-table doesn't prohibit the hide of a column → once hidden, a column cannot be made visible again
• missing slots for each column to allow custom rendering

• prop search-value should be named search-term
• prop disable-search should be enable-search or searchable
• prop allow-row-selection should be enable-row-selection or rows-selectable
• prop allow-bulk-edit should be enable-bulk-edit or bulk-editable
• prop allow-bulk-delete should be enable-bulk-delete or bulk-deletable
• prop enable-outline-framing should be show-outline-framing
• prop enable-row-numbering should be show-row-numbering
• prop disable-edit should be enable-edit or editable
• prop disable-delete should be enable-delete or deletable
• prop disable-settings-table should be enable-settings-table
• prop current-page should be pagination-page to be inline with pagination-limit and pagination-total-items and it's event pagination-current-page-change

• event pagination-limit-change should be update:pagination-limit
• event pagination-current-page-change should be update:pagination-page
• event sort-change should be update:sort
• event search-value-change should be update:search-value
• event open-details should be item-edit to be inline with item-delete
• event change-show-outlines should be update:show-outlines
• event change-show-stripes should be update:show-stripes
• event change-outline-framing should be update:enable-outline-framing
• event change-enable-row-numbering should be update:enable-row-numbering

[Michel (cyl3x)]

mt-select

Have proper opening and closing events for the result-list. This would allow better asynchronous fetches and resets.
More importantly, I could use such events to trigger sw.location.updateHeight() to adjust the iframe height of too small iframes, where the result-list would otherwise be in a rather small viewport.

[Nils Haberkamp (Haberkamp)]

Thanks for the feedback! This is very much appreciated. We're well aware of some issues like the modularity. We have plans for the future to improve three-shaking and only outputting the styles for the components that are actually imported. Regarding the flexibility we try to strive for a balance. We want the components to be flexible in a way that allows people to achieve the things their need to do but we also want to restrict certain things to have a sense of uniformity. I agree that some properties should be renamed or changed. Though we need to be careful not to break too many things as this makes it harder to adopt Meteor in some projects where a big migration could bring development to a hold.