UI base components lib?

[fxprunayre]

Currently we are defining all UI basic components (eg. progress bar, drop down, button, step bar) from scratch in
https://github.com/geonetwork/geonetwork-ui/tree/master/libs/ui/src/lib.

For example, if we want to have a simple selector to choose the layout of results. The list of layout is also using an icon and when selecting a layout, the icon become the selector label. Nothing fancy.

But if I want to do this with current ui/dropdown-selector, we have to:

• add options for no label
• add support for icons in options
• add support for label with icon
  ... then we may need grouping, disable, multiple, error messages, keyboard interactions ...

All this could be done directly with libs like angular-material. Quick experiment:
https://apps.titellus.net/catalog/gn-ui/search/
https://apps.titellus.net/catalog/gn-ui-material/search/

Why not using some existing libs for this? Pros&cons? From past discussions on this topic I remember; main complains:

• Do more than you need
• Size
• "All sites look the same"

But on the other hand

• Speed up dev and works well
• Can make theme
• Keep things consistent (when we will start to take a calendar component from here, a typeahead from other places ...)

Is this something to discuss ? @fgravin , @MichelGabriel , @pvgenuchten

Personaly, I'm not sure we:

• are adding any values in designing our own low level components
• have resources to build all that from scratch, maintain that and make something consistent on the long run

[fgravin]

I do agree it could be a lot of work to create our own UI components, and it's not really valueable.
On the other hand, I don't know if we will have that many component to create. Note that maybe the dropdown component has not been designed the right way, we could take advantage of ng-content stuff to handle more easily the content list (icons, labels etc..)
It's also the best way to end up with the look and behavior you expect, the look is statisfying so far.

It's true that bootstrap components where great and easy to use. We don't use bootstrap in geonetwork-ui to bring some fresh air in the UI, but also because it does not handle CSS variables, but it seems they are including them somehow (we might need to take a closer look) https://getbootstrap.com/docs/5.0/customize/css-variables/
BS5 has no jquery, so easier integration with Angular.

I am not favor about angular-materials cause it clearly imposes the look of your component, the google-material way, everything has to be material or not, otherwise the UI will look weird. I agree that have great 'ready to work' components though.

This is a complex topic, seems @jahow and @MichelGabriel already took some time to consider pro and cons, now after some months of dev, maybe the vision has changed.

I can't really decide about that, i didn't use TW at all, it look promising and except about the ui components, it brings satisfaction and is largely customisable. Maybe turn back to BS5 could be considered as well.

I let other give their opinion.

[fxprunayre]

On the other hand, I don't know if we will have that many component to create.

Thinking GeoNetwork as a whole (search/map/edit/admin), I think we are using almost all of https://getbootstrap.com/docs/3.4/components/

angular-materials cause it clearly imposes the look of your component,

Not an expert on that, but it looks like there is option to extend components and overlay css https://material.angular.io/guide/customizing-component-styles

i didn't use TW at all

I did not much on tailwind too but it was quite good and flexible so far - with it we can probably write almost no CSS.
Updating to tailwind 2 was easy in the material test branch and was working fine to size and position material components too.
About CSS variables, it is not yet clear of what are the benefits - at least we are missing concrete examples.

[jahow]

Hi, the dropdown component is actually the one thing that made me regret bootstrap the most. Recreating a dropdown from scratch is a lot of work as it needs logic for showing a popup, handling keyboard navigation, accessibility concerns, etc. Regardless, during my experiments I had a dropdown about 75% finished, I still have the branch somewhere. Popper.js does a lot of the heavy work anyway.

Bootstrap 4 does not support web components so I guess it's out of the question.

Not sure Bootstrap 5 or angular-material will work well in web components, using one of these frameworks (or any other for that matter) is taking that risk.

In my opinion using a CSS/components framework isn't that huge of a win and brings many other issues as well:

Pros:

• Complex, logic-intensive components (dropdown, modal, typeahead, date picker) are already made
• Helps with accessibility
• Consistent and good-looking theme
• Widely used

Cons:

• May require a double dependency: with the lib and with the angular binding (e.g. boostrap and ng-bootstrap)
• Usually comes with a design orientation
• Most likely not theme-able with CSS variables
• Components might end up doing not exactly what is needed; a good example would be a date picker that would miss some features; then, we'd have to bring in another library anyway; we've had trouble like this in the past with ng-bootstrap
• Surprises may arise when using the framework in a web component
• There are many very good libraries for making date pickers, typeahead is mainly a dropdown with some logic, modals aren't that hard to make either, and no need for them have arised yet (I think); all in all, it really comes down to having a dropdown component ;)

Some example of things that ended up being custom components in GN legacy ui:

• tags input
• typeahead/autocomplete
• button with spinner

And there is a lot of code to wrap the bootstrap components and offer functionalities specific to Geonetwork, so it was not exactly "include and forget".

In my opinion going with a framework is taking a risk, making development faster in the short term but potentially causing issues and constraints in the long run.

As for CSS variables, there is a concrete example: the web components that were funded by the EEA. Although they don't show much of a theme, their colors can still be changed dynamically. Not using CSS variables means going back to the current system in GN4 where colors are defined in the admin, saved in the database and the datadir, and require a new portal for each set of color.

My 2 cents :)