Features / breaking changes for 2.0

[laurensgroeneveld]

This is an issue to gather feedback for features and especially breaking changes we should introduce in a 2.0 release, which isn't far away. So far I've the following things that we definitely need to do:

2.0 todo

• Make button centered by default in CSS #260: the Vue library already has this default, but it adds a CSS class. Rather the text should be centered by default, with a CSS class for the non-centered variant
• icon prop on Alert: Since Add neutral option to BccAlert #215 this prop can be both a boolean (to indicate whether to show an icon) and a Component (to pass a custom icon). The latter is the way it's done in other components, so I think we should introduce a separate showIcon or withIcon boolean prop for the first case (up for discussion: whether setting the icon prop means an icon is shown by default). => on second thought the current way seems to be pretty ergonomic, so I think we should keep it that way.
• Update typography to new Figma design #251: This was first introduced in Updated typography #249, but reverted. The typography styles in Figma have been updated and renamed, so this is a breaking change. This also means updating all the components.

Target date

We're thinking of releasing in 2-3 weeks, 12 October is the target date for now.

[u12206050]

I've been going through some of the form components now, as we are busy looking into how to make a schema for forms. However, it seems that each component is implementing the label and message part them selves instead of this being in a wrapper "field" component.
So I wonder if we should update all the form field components to be more aligned such that it is easier to generate forms based on a structure where we can expect all fields to work roughly the same, eg. all have disabled states, option for full or half width, etc.

If we take the current Interface from Directus components which basically just needs you to take in a value and emit the new value, it does the rest of wrapping it in a "field" component with the label and other options such as a note.

It might be though that this type of change is too big for this release or?

[laurensgroeneveld]

So I wonder if we should update all the form field components to be more aligned such that it is easier to generate forms based on a structure where we can expect all fields to work roughly the same, eg. all have disabled states, option for full or half width, etc.

Do you have an example on how that would look? Not sure I entirely understand where this field component comes into play: is it just internally to make maintenance easier, or do we expose it to the user?
The public interface of the current components feels fairly similar, with every component exposing a label, disabled prop etc. and extra props where it makes sense (like indeterminate for the checkbox).

option for full or half width

Personally I would not prefer to make visual options like that part of the library since it can very easily be handled by utility classes, and by overriding the CSS class it's pretty easy to set a different default for your project.

[u12206050]

So the idea is we are going to create a form component, that can take in a schema of fields that it would then generate a form for. So the form would do stuff like client validation and conditional logic, and be able to set the properties such as disabled, error etc.
That requires that the interfaces used in a form conform to the same set of options to be usable.

[laurensgroeneveld]

So the idea is we are going to create a form component, that can take in a schema of fields that it would then generate a form for. So the form would do stuff like client validation and conditional logic, and be able to set the properties such as disabled, error etc.

Makes sense 👍 Then I understand more of your suggestion of adding visual options as well, although adding the ability to add abitrary classes in your field schema would be something I suggest in any case.

That requires that the interfaces used in a form conform to the same set of options to be usable.

That is already the case right? You can pass a label, disabled, and modelValue/v-model to every form component. Do you perhaps have a link to how Directus implements this?

I do see that label doesn't mean the same for the BccInput vs the BccCheckbox for example, as in the first it's the label for the whole field, in the second case it's just the label for that specific option. But that could be handled by the Form component.

[u12206050]

After a discussion with Reng, we have decided as a starting point to use the same Form/Field schema from Directus, this immediately gives us a blueprint of both how we can build up forms in json, as well as how the components interface should look. Take a look at the Directus components here especially the v-form component which we will attempt to create for the our design system on the Frivillighetshelg.

[laurensgroeneveld]

Closed with the 2.0 release - the form builder will go in a 3.0 release if it has breaking changes.