Component marketplace

[Rich-Harris]

Just putting this here (rather than on Gitter, where we'll lose track of stuff) so we can collect any thoughts we have about promoting an ecosystem of components, to make it easy for people to start building more complex apps.

A few starter thoughts in no particular order:

• should probably live under svelte.technology, to give people confidence that it's an officially supported thing (https://kit.svelte.technology, perhaps)
• component package names on npm could follow the svelte-kit-[name] convention. (do we want to reserve that for officially supported components? or all community ones too?) should be easy to search npm that way, without relying on keywords (which I think is a less robust approach). maybe scoped packages is the way to distinguish between 'official' and 'community' components, if we want to do that — @sveltejs/svelte-kit-scroller and so on
• maybe a component doesn't need to be an npm package to be shareable. maybe a gist would be good enough — standard format, easy to view source, easy to fork... npm does provide people with a higher level of confidence though, and various other advantages
• should accommodate packs of components, e.g. if someone made a bunch of Bulma components (or whatever — I don't know if Bulma 'components' even makes sense, it's a CSS framework. But people have brought it up in the past)
• ought to be searchable, and provide an easy way to try things out (e.g. in the REPL)
• should provide guidance on best practices around testing, linting, shipping compiled and uncompiled versions, etc. Though it shouldn't be too opinionated, because opinions change, and then you're left with parts of the ecosystem that seem stale. A given package should have as few files and dependencies as possible
• there's other stuff besides components — custom event handlers, transitions, extra methods etc. maybe they should be here too

cc @arxpoetica

[arxpoetica]

Agree on all merits.

On point 2, I think your recommendation on scoping makes a lot of sense.

One point 3, I definitely think allowing gists opens up all kinds of pros and cons. It breaks with convention. (But P.T. Barnum never followed convention!) On the other hand, the bar for entry into npm is kind of high, so there's definitely a case to be made for greasing the rails and making it easier to gist something. We can experiment with this; at the end of the day a REPL would be even simpler, so a gist might be the right direction toward that end.

Interesting point about packs of components. Maybe namespacing @whatever/svelte-kit-* would be a convention to generally apply to any username or group. This is getting pretty ahead of the game, but an ecosystem would need users w/ usernames, so @namespace makes even more sense, especially when someone else wants to officially support one's own set of componentry. I like this idea.

Definitely yes on search, but that doesn't need to come first. Don't let that uphold anything out of the gate. Second tier work.

When you talk about best practices, is that component level-specific or general?

On the last point, I almost feel like that's a seperate ticket/consideration. SO. MANY. questions there. Almost more toward that REPL thing you were discussing. Maybe we should itemize what needs support and what doesn't. Separate issue? I vote on limiting this issue to JUST components, and then offshoring the rest to another day/time/ticket. With the quick feedback that YES all that and all this is ridiculously awesome. I've been dreaming about stuff like this for yeeeeeears, and Sapper is making it (potentially?) (fingers crossed?) (knock on wood?) possible.

I'm dubbing this ecosystem @GriffinJS, "King of all (js) Creatures"? @horsejs bows to @GriffinJS.

[arxpoetica]

Thinking about this more, I think breaking with convention might actually be good, so yes to "gist-ing." The general philosophy I've heard you voice before about making things easier for onboarding devs—gisting would lend perfectly to that. Let's lower the barrier to entry.

[PaulBGD]

The biggest issue I've thought about with installable components is how you handle the styling. Sure you could make a component accept a bunch of configurable options, but that's annoying for everyone. Something I've though about is a way for a style to target a child component, which could allow it to pass CSS variables or something like that. This is probably a completely different issue, but I do feel that styling is one of the biggest issues with importing 3rd party components.

[arxpoetica]

Ah, yes, great point @PaulBGD. BOY do I have some opinions to that end... :) I'll chime in when I have a chance.

[arxpoetica]

Actually, really quick before I forget. The main thrust of my argument is no to very little styles, i.e., so skeleton that it is ugly, but (and this is the thing I don't want to forget), styles should and ought to be treated as separate from components almost. This might sound weird since a component ought to be all inclusive, but, as @Rich-Harris pointed out above, what about custom event handlers, transitions, extra methods. I would definitely land styles in the excess baggage category, even though we tend to think of a component as a component with styles.

So a component ought to be able to have different styles easily applied or dropped, separate of the component itself. With (MAYBE) just some bare opinionated skeletal styles, but I'm wary of even that.

Definitely some room for argument here.

[arxpoetica]

Oh, but wait a minute. @PaulBGD you're over thinking it and so am I, ha ha ha. The whole point of this ecosystem isn't to configure something. It's to either use the opinion or just overwrite the flippin' thing.

But like I said, definitely room for argument.

[gavinmcfarland]

@arxpoetica very good point. It will most often boil down to either being opinionated or very open. I guess this will depend on the author's ambitions, my gut would say that most would be opinionated due to the nature of how layout influences markup.

Another thing to consider is that I suppose some components might not even be visible to the user? They may work in the background. In this case style would absent.

[emilos]

Just as an idea, maybe we should also consider consuming other ecosystems? It would be interesting to see how many packages we could use from https://www.webcomponents.org/ or maybe even from https://curated.vuejs.org/ etc.

I'm not sure if that'd be easy in most cases but I think it's worth investigating.

[arxpoetica]

@emilos definitely. Maybe this is presumptuous, but I think @Rich-Harris's and my original convo on this topic was a little more far-flung than what other ecosystems offer. In terms of how to author a plugin, but that's getting ahead of the game. I think you're very right in the sense that it makes no sense to reinvent what has already been done.

[arxpoetica]

@mindthetic and @PaulBGD having thought about this more (regarding styles), from my angle the worst thing on the planet (I'm a purist) is Bootstrap and Foundation and the like. There are some very strong opinions in there. But some people looooove them because they are easy to use and opinionated. Like, so easy out of the gate to just use.

I've always thought they were fundamentally flawed, however, because once you get past "out of the gate," so to speak, maintaining code base becomes extremely unbearable and untenable. All those opinions start wreaking havoc on whatever one is trying to do—from a style POV—and time to whatever needs to be done starts adding up.

So, on the one hand, opinionated components make complete sense for one-off hobbyist projects, etc., etc., but where things start becoming just another opinionated thing is in terms of longer-term projects where people get mad at the opinions. And this is especially true of the CSS.

I think the issue on how to compartmentalize CSS in a component marketplace bears really digging into the conversation, trying to think if there's a creative solution that, win-win, makes everyone happy. That might be impossible. I'm an optimist. Cue circus-leader @Rich-Harris. Any thoughts to this end?

[arxpoetica]

Sorry, one more thought, but one way to be opinionated and open at the same time is to detail in the documentation of a given component how things fit together, and how to replace them. Ye grok?

[gavinmcfarland]

Perhaps the topic of how to handle style should be discussed in another thread? I have quite a bit to contribute to it, although not necessarily answers.

[tomcon]

The ability to support app-wide change of theme(s) is important on this subject too.

You can switch the main stylesheet and you get a completely different look and feel based on the same class names.

Don't know if svelte re-generates the css class attributes randomly each time or not, but if so this would probably mean application-level theme changing is not possible.

If the class attributes were a predicable unique combination of (say) .classname[svelte-[component name]] then perhaps this would overcome the problem as theoretically it should be never be able to used elsewhere inadvertingly?

[gavinmcfarland]

As components become more popular and there is less of a need for for frameworks perhaps it's not the components that need a market place but the aspects that make up the components. For example styles themselves, and interactions. The trouble with theming is that it works great when the other components you're using have the same theming options but mix components together and it's a mess. I agree with other's that this is an aspect that needs digging into deeper.

[lnryan]

Chiming in here - 2 things:

1. I really like the ideas of having a common svelte components repository. Perhaps the solution in this space the whole opinionated/open quandary is to deliberately break these into paired components: eg DataTable (only what's functionally necessary and provides unimplemented classes?) and a DataTable-Styled that nests the first and implements the style-classes?

2. How would this work with combinations of namespaced npm modules and truly private modules? Also how would namespacing work. If I use a Checklist component from the svelte-kit-workflow i would imagine the following to show up in my application:

   
   <Checklist bind:data='todos' />

import { Checklist } from 'svelte-kit-workflow'; ...

but what if I needed to use two components from different libraries. it's a stretch with one called Checklist, I realize...

if i have `@sveltersunite/kit-workflow` providing one `Checklist` and another completely private one that i include in package.json

"dependencies": { "super-secret-components": "spymaster@github.com:spymaster/super-secret-components.git" },

This should be enough to use them both right?

but is there be a way to be able to use `<sveltersunite:Checklist>` and `<spymaster:Checklist>` instead? being able to optional preserve the namespace of the source in the html helps manage assets better and keep track of where they come from. 
thoughts?

[arxpoetica]

@mindthetic I think it's fine to keep the styles aspect in here. It's definitely on point. We can always break off anything that actually needs its own ticket.

@tomcon I definitely agree with you on the scoping problem Svelte creates. .classname needs to be prioritized if we're going to have a marketplace. This probably deserves its own ticket. I'll slice that one off...

@lnryan I like where your mind is on this. Getting all the way to <sveltersunite:Checklist> though really would be a magic trick. I wonder...

[aubergene]

I'm interested in the ideal of compiled versus non-compiled. I guess it relates to #742.

I think this will be an amazing addition to Svelte!

[arxpoetica]

Inspiration?

https://news.ycombinator.com/item?id=16467387

https://pagedraw.io/

[arxpoetica]

Relevant: https://medium.com/@tomsoderlund/micro-frontends-a-microservice-approach-to-front-end-web-development-f325ebdadc16

[GarrettGeorge]

After using Vue for over a year and a half the biggest problem I have with using other people's components is, the second I have to make a custom change or implementation, CSS, event handling, bubbling, etc. it seems impossible or hack-y.

Ideologically I think Svelte should emphasize light-weight, bare bones, and unopinionated components in this "component marketplace". And instead of the component creators' vision, namely styling, being the default, the default is the skeleton and someone using the component would need to specify that they want to use the creators' styling.

Ideally I think components in this component marketplace should have some standardization of component lifecycle hooks that the parent component using them has access to in order to potentially alleviate some of the difficulties with trying to work around opinions of pre-made components.

[devth]

I'm new to Svelte but came here while looking for a way to build and publish a simple component. I want to dive into Svelte itself and not have to mess with:

• how to build, publish
• testing
• storybook
• consume styles from css frameworks like bulma without including the entire css payload

basically all the dev UX stuff.

I think a component marketplace is great but first we need a happy path to building components in the first place. My goal would be to port a little React component I built to Svelte, publish, and consume it from a web site. After looking around it's not clear how I'd do that without diving into dev workflow chores.

[btakita]

It would also be useful to componentize all scss/css to keep the payload slim.

I added a proposal in the sveltestrap project https://github.com/bestguy/sveltestrap/issues/14. This pattern can be applied to any existing toolkit (Bootstrap, Foundation, UIkit, etc.)

https://github.com/sveltejs/svelte/issues/2762 would be important to enable global styles to be imported/interoped from third party styles & components.

[dimensi]

It would be cool to have an analogue of vuepress or something, but with the svelte theme for documentation. So that the authors of libraries for svelte did not suffer from the choice of documentation generator. Although perhaps the idea of a marketplace does not violate the idea of svelte that components from svelte can be transferred anywhere since it is vanilla js and there is no attachment to the API framework :thinking:

[jakobrosenberg]

Just wanted to add that if anyone suggests a Svelte specific package manager, you need to shoot them dead on sight.

Meteor used to have its own package manager and even though it was near flawless, it helped establish Meteor as the special, but closed off kid, that wouldn't get along with others.

[swyxio]

agree on much of the above. i think figuring out the right standards we want in an officially endorsed marketplace is going to take some time. we just kicked off moving https://github.com/ryanatkn/awesome-svelte-resources to https://github.com/sveltejs/community/ and i reckon we can agglomerate more and more quality components and feel out what they have in common.

[arxpoetica]

@jakobrosenberg mostly agree, i.e., don't reinvent NPM since NPM is a repository.

Related: we've been using the word marketplace, but maybe there's a better word like registry or repository since really it's not about buying or selling.

@sw-yx maybe awesome-svelte-resources is enough for now. I've been sitting on this ticket for quite some time trying to figure out the right thing to do—the main wish is just an easily searchable index that goes slightly beyond what NPM does—

But then the idea of reusing things and being able to restyle them as needed isn't really that easy with just NPM "components" unless we add some sort of injection model or unpacking principle easily overriding or using as a template, etc.

Like maybe it's as simple as having a standard way to utilize degit for getting components into a workspace.

Thoughts?

[arxpoetica]

[see also: https://github.com/ryanatkn/awesome-svelte-resources/issues/18]

[antony]

@sw-yx @kevmodrome @pngwn this feels like something we'd cover in the society/community site?

[kevmodrome]

Yes. This sounds like a good fit. Could use the REPL to show gists/implementation/how to use details. Maybe make an issue in the site repo or a comment in the project structure issue

[arxpoetica]

@antony I think Svelte Society is exactly the right place this sort of thing can happen. Since @Rich-Harris originally opened this ticket on my behalf, and since you've now cross-linked to this at the Society repo, I think we can safely close this ticket. :)

Excited to see a new home for this that feels like the proper place.