Simpler package structure

[tpluscode]

Wanting to dynamically import only a single element not has to deep dive into the dist-src directory:

import('@aybolit/material/dist-src/components/abm-button').then()

I find this uncommon as well as providing a bundled js file as the default index.

Instead, I propose a simplified build where individual components are imported by default both statically and dynamically.

import '@aybolit/material/button'
// equal dynamic import
import('@aybolit/material/button')

If desired, the bundled build would stay but being the non-default alternative

[web-padawan]

Thanks for the issue. Actually, I was thinking about making each component a separate npm package (like most of people in Polymer community are used to). Would that solve the problem for you?

[tpluscode]

Sure, that would also be less surprising and indeed Polymer elements do come to mind as an example of established practices.

On the other hand some paper/iron packages actually come with multiple custom elements. Do you think it's worth separating each aybolit package into individual package per component? Sounds like a lot of packages :)

[aveiga]

Hi,

I’ve been eying this repo since I’m working on an industrialized ui toolkit and we’re now defining our design system.

From our experience (we only use web components and, for now, Polymer) working with different repo’s per component turns into a mess pretty quickly. I much prefer the import '@aybolit/material/button' approach, which is the approach that libraries like reactstrap or web-components-material-web-components (whatever the name is...) use (in different eco systems, obviously).

I believe the Polymer team also came into that conclusion as that’s what the material team is now doing (and the paper-elements are dead, anyway).

Hope I was able to help 👍

[web-padawan]

@aveiga thanks for your opinion as well. I would prefer to collect the feedback before making any decisions, yet there is plenty of time until 1.0 release to revamp the structure.

working with different repo’s per component turns into a mess pretty quickly

That's not what I meant. There would be still 1 monorepo, but the structure could look similarly to what I've been experimenting in https://github.com/web-padawan/lit-components

[lkraav]

@web-padawan 1mo later, what are your latest thoughts here?