Re:ING open-sources Lion, a library of accessible and flexib...
by benforreal on Thursday February 13, 2020 @04:20PM
(#22321535)
But a build process ensures you can use imported dependencies internally AND use them with zero dependencies on your page (other than the JS component definition itself). Even if you don't have a build process and just use ES6 modules, the Web Component manages its own dependencies such that you don't have to worry about it (the only friction there being if folks use bare import modules). Whereas with React components, you'll always be dependent on a React runtime.
[ Parent
| on HN ]
Re:ING open-sources Lion, a library of accessible and flexib...
by Vinnl on Friday February 14, 2020 @12:47AM
(#22324246)
What happens when different modules register custom elements with the same name?
Re:ING open-sources Lion, a library of accessible and flexib...
by d4kmor on Friday February 14, 2020 @08:00AM
(#22326121)
There are various techniques you can apply in these cases. Like deduplicating dependencies or apply a build/babel plugin that makes sure the names are unique.
Imho scoping elements at the template/element level sounds more promising. Here is an experiment archiving exactly this https://open-wc.org/scoped-elements/ There are still some improvements to be made but it's actively been worked on - so something lion might consider in the future.
Re:ING open-sources Lion, a library of accessible and flexib...
by Vinnl on Friday February 14, 2020 @10:25AM
(#22327314)
That's great, that would've saved us so much trouble back when I worked with Web Components with many different teams. The problem it describes are exactly what we ran into, and solution 2 was extremely painful in terms of overhead and being demotivating:
> Synchronizing updates of shared dependencies - e.g. make sure Team Blue & Team Green always use the same version when releasing. This can be a viable solution however it comes with a high organizational overhead and is hard to scale up (for 10+ teams)