Multipart components? Sub-components?

[evs-chris]

Some existing packages have sub-pieces that are part of the same build. For instance take purecss.io, which spits out a handful of component and aggregated css in both responsive and non-responsive flavors.

In this case, adding a component.json to the main repo is basically useless unless you're only interested in a single flavor of a single component or aggregate. Having a fork for each sub-component and flavor creates a tremendous maintenance headache.

I don't know if this is a use-case that component wants or needs to handle, but there are many decent existing libraries that have build output like that that would benefit from some sort of sub-component breakdown in component.json. Perhaps having scripts and friends definable as objects (in addition to the existing flat arrays) and allowing them to be addressed individually, as say 'buttons@pure' or 'grids@pure', as well as together as simply 'pure'.

Or is this entire scenario something to be kept painful-to-support to discourage overly complex components?

[timaschew]

you mean something like this: https://github.com/component/bundler.js ?

[evs-chris]

Unless I'm missing something (entirely possible), that seems to be more geared toward packaging an app into components for internal (local) consumption, rather than packaging a component for publishing for general consumption. In the cases I've run across, I have an existing project with multiple outputs that can each be considered a component, but there is no way to easily package each in an individual component since they all derive from the same code base in the same repo.

Another solution would be to allow a sub-directory of a repo to house individual components i.e. yui/pure is the aggregated component and yui/pure/grids is its own component directory that references the grids.css output from the build directory in yui/pure. I have no idea if this is already possible in some way, but it doesn't appear to be.

But, again, I'm not sure that this sort of support isn't contrary to the goals of this project. My question primarily revolves around getting component support in existing projects that are already committed to bower and/or browserify. If they can add component support without having to completely rearrange their code-base, they would be much more likely to accept a pull request to do so; thus removing the need for component-ized forks that are subject to bit rot.

[jonathanong]

at this point, this "component" abstraction becomes too complex. it's really not worth the complexity.

[evs-chris]

That's fair.

I have one last (slightly rephrased from above) query as I close this issue: is there any chance that any sort of sub-component reference would be simple enough? For instance what if a component named 'yui/pure#grids' could behave exactly as 'yui/pure' in all other ways except pull the component.json from http://raw.github.com/yui/pure/whatever-tag-uri-parts/grids/component.json instead of http://raw.github.com/yui/whatever-tag-uri-parts/component.json? The paths in the json would still be relative to the repo root, but there would be the potential to reference aggregate projects without multiple forks.

[jasonkuhrt]

FYI some of this seems related to https://github.com/facebook/react/issues/1635 wherein each react add-on would have to be its own repo etc.