Create contributed index of SDCs similar to contributed modules and themes.

I do agree, SDC seems like it will become a soup similar to Layouts having every block type out-of-the-box. We'll have Components dripping out of everything. It's one thing to have a Grouping for those following specific 'School of Design' or Javascript [beyond jquery/behaviour use]..

This will be key in helping Recipes/Profile builidng too.

I am not clear what you mean by soup for SDCs but this issue is more about the discoverability, organization and the ability to include contributed SDCs in Drupal projects / modules.

Let me sketch a couple of ideas to help clarify:

As a sitebuilder I have been tasked with including an accordion on a page, I have created the content structure already and now need the front end. It would be great to have a place on d.o. to utilized vetted (and accessible) accordions that are SDCs. Once I find one that works for my use case the ability to include it in my project and tie it into my theme so my content uses the SDC.

As a front end developer I have built an accordion and use it on multiple projects. It would be great to be able to manage the codebase in one place and include it in multiple projects. This allows me to pull in updates in existing projects as bugs are fixed in the SDC.

As a design system maintainer it would be great to be able to group my SDCs into one package for consumers to include one package and get all SDCs (or a specified subset of SDCs).

As a module maintainer it would be great to be able to use contributed SDCs for elements I would like to display (e.g. a table). This would cut down on the amount of time I would need to implement css and styles myself if I can use a popular contributed SDC.

As a theme developer it would be great to include several contributed SDCs as a starting point for layout and structure.

I think these use cases / requirements can be fleshed out, but I hope this illustrates my idea more clearly behind contributed SDCs and integrating closely with d.o infrastructure.

soup == group.
sorry, autocorrected.

IMHO, since SDC can be implemented theme or module, it doesn't make sense to create a new project type. For now a tag or flag saying this module/theme implement components in SDC format would be good.

@SKAUGHT, yes exactly.

I think there needs to be some uniqueness to the type though because we would want to group them together more tightly in some cases.

@Sharique, I think there is extreme value in stand alone front end SDCs because then modules / themes can implement or require SDCs maintained by other users. If I'm not a front end developer, but I want something nicer for my module interface being able to include an SDC maintained by a skilled FED would be a huge benefit.

Ultimately since the SDCs are yml defined I could envision some auto discovery on the project page showing which items are able to be overridden and some sort of inline display of what it looks like in real time. I think that's for another issue though.

I love @nicxvan's use cases, but I'd like to add one...

As a site builder, I'd like to be able to find components and integrate them into my site in a low code/no code way. This could be through layout builder, blocks, views, or other UI elements in the site.

@Sharique, I'm agnostic on whether components require a new project type or not. But I feel they should be discoverable without a need to know they are buried in a particular project. Being able to search for a particular component type and add it to my project shouldn't need me to know it exists in a module or theme.

I think having a dedicated component project type could be useful and could give developers an easier route to contributing to Drupal without needing to know too much about structuring Drupal projects. However having a component browser that could find components across multiple project types would ensure the maximum availability of components to sites.

I agree with nicxvan
- At this time it feels that all SDC components can be a general project. ( but they must delivered to a module or a theme )
Adding to that:
- Use of composer or ( npm, yarn, ... ) ( I'm with npm ) to be in the npmjs.com site or a private Drupal nodejs app store.

Only suggesting:
SDC components with versions, can be managed easily:

Option #1: Use the same https://packages.drupal.org ( using the composer and install-path )
Option #2: Use the https://npmjs.com ( using npm, yarn, ... + a script ( wepback ) to copy SDC components from node_modules to a targeted module or theme
Option #3: Use the https://asset-packagist.org ( with composer and trite SDC as we work with libraries ) but with a different target .. ( it could have a type of drupal-component, drupal-sdc and the assigned type will have an install-path for it.
Option #4: Use a custom npm.drupal.org, components.drupal.org, or other web apps hosting for components.

Yes, a component library would be great!

It would be awesome to be able to download ready to use, styled components from an online library, such as these:

• Call to Action
• Team members (photo, name, position)
• Buttons
• Pricing table (three products, side by side)
• Etc.

Copied from Mercury Editor issue ✨ Online component library Active .

I think for a minimum viable project we need a few things:

• A critical mass of contributed SDCs
• A way to browse SDC options
• A way to include SDCs

I think a couple of corollaries of the above.
A way for people to contribute.

I think a contributed module for the library might work as a starting point for building the critical mass.
The contributed module would allow anyone to contribute an SDC as long as it is namespaced and follows conventions defined by the module (e.g. props and slots must be defined)
Ideally the module would provide a way to browse the components and a way to enable / disable them.

Alternatively there could be a second module for browsing the SDCs in the first module. This second approach has the advantage of only including the SDCs you want.

I'm curious what people thing about these and any proposed guidelines for SDCs in the module if that is the route chosen.

My take is that it is seldom useful to contribute a single component. I am sure the use case exists, but it will not be the norm for sure. I think that a "bundle" of components (a school of components? a gaggle of components?) will be the norm. Like in other technologies.

I agree that this feature is very useful. We thought about it a bit when designing SDC. Our idea was that a this bundle should be a module. You can have a module that only contains components. Components are discoverable within a module, and have rich metadata (like thumbnails, README, schemas, descriptions, etc). It is not too far fetched to imagine that you can search for an accordion component in project browser, and you find the Simple Components Extras Plus module.

Using modules has certain key advantages:

• They already have documentation on how to author them, how to download them, how to enable them.
• They already have the technical tools to author them, download them, enable them.
• They have the concept of versioning built in.
• They have the concept of a dependency chain built in.
• A component cannot currently exist in isolation since you put them in the page by: my-module-or-theme:my-component
• Modules can also house dependencies for the components, like new Twig filters.
• Modules can also contain tests. And our CI tools also know how to run those tests.
• We have tools to upgrade modules (and the components within)
• ...

This seems to go inline with some of the comments in this issue.

I like this, maybe we just need to modify project browser to allow displaying some examples of how they look when a user chooses them.