Encapsulation and ease of reusability / configuration?
Just as an example - a widget to manage a list of number ranges. Build it up like a form element - it provides a value prop with the type ‘[number,number][]’
You need to display the current collection of min/max pairs, and add / remove / edit the collection - it’s essentially a mini CRUD component.
There is no default html element that provides this functionality - you need an ordered list of pairs of number inputs, a confirm changes button, a ‘add new’ and ‘remove this entry’ button - you need a whole collection of stuff to provide the functionality.
But once you’ve got it all worked out, wrap it in a web component and you can use it in 8 different places across your admin tool - ‘<ranges-picker />’ and boom, you’re ready to go.
Using web components to define a library of common interface elements works just fine.
Right, but react solves the problem as well with similar amount of effort, but everyone is already on react. So switching is cost with little perceived benefits
Just as an example - a widget to manage a list of number ranges. Build it up like a form element - it provides a value prop with the type ‘[number,number][]’
You need to display the current collection of min/max pairs, and add / remove / edit the collection - it’s essentially a mini CRUD component.
There is no default html element that provides this functionality - you need an ordered list of pairs of number inputs, a confirm changes button, a ‘add new’ and ‘remove this entry’ button - you need a whole collection of stuff to provide the functionality.
But once you’ve got it all worked out, wrap it in a web component and you can use it in 8 different places across your admin tool - ‘<ranges-picker />’ and boom, you’re ready to go.
Using web components to define a library of common interface elements works just fine.