svelte-society/sveltesociety.dev

Proposal: Submitted data restructure

Closed this issue · 6 comments

lachlancollins commented

💭 Problem

I've found that the "Components", "Tools", and "Templates" distinction isn't always logical. For example, @sveltejs/adapter-auto is in components.json, while vite-plugin-svelte is in tools.json. "Components" in particular is far more than just UI packages. It would be easy to miss a package because you don't know where to look.

In comparison, I've found the SolidJS Ecosystem pages to be very well structured and logical. They divide their content into "Packages" and "Resources".

🚀 Proposal

I think the packages vs resources division makes a lot of sense. Here is how I think the current data could fit this:

/packages

  • Things that you can npm install and add to package.json.
  • Sourced from current components.json and tools.json.
  • Using the above example, both @sveltejs/adapter-auto and vite-plugin-svelte would be included on this page.

/resources

  • Templates, sample projects, extensions, tutorials, podcasts, etc.
  • Sourced from current templates.json, tools.json, and /resources.
  • For example, SvelteKit i18n Template, Svelte DevTools and Svelte for VS Code would be included on this page.
  • Opens the door for more resource submissions (e.g. I can't find any references to Joy of Code's channel)
benmccann commented

I agree components and tools could be combined. I'm not sure where I'd have the list of editor extensions live, but the rest seem fairly overlapping

I'd keep templates and resources separated. Solid's resources are limited to articles, videos, and podcasts, which is a more reasonable grouping to me than mixing templates in. Especially since we have so many templates it'd overwhelm the rest of the content

  • 👍1
lachlancollins commented

I agree components and tools could be combined. I'm not sure where I'd have the list of editor extensions live, but the rest seem fairly overlapping

I'd keep templates and resources separated. Solid's resources are limited to articles, videos, and podcasts, which is a more reasonable grouping to me than mixing templates in. Especially since we have so many templates it'd overwhelm the rest of the content

Thanks for the feedback! Great point about keeping templates and resources separate. Here's how I think this could work:

/packages:

  • Sourced from current components.json and tools.json (excluding browser and IDE extensions)

/templates:

  • Unchanged from current templates.json

/resources:

  • Current resources page converted into JSON, and extensions from tools.json
MacFJA commented

For me, we need to separate (at least) what is need to create the application and what help to create the application and DX improvement.

Need to create:

  • Component libs
  • UI libs
  • Vite plugin to transform data
  • Preprocessor
  • etc.

Help to create:

  • IDE plugins
  • Prettier plugins
  • Templates
  • HMR plugins
  • Documentation generation
  • Tutorials
  • etc.
benmccann commented

The need vs help difference sounds like a pretty difficult line to draw. I would be surprised that vite plugins and preprocessors are on one page, but HMR plugins and prettier plugins are on a different page.

MacFJA commented

The need vs help difference sounds like a pretty difficult line to draw.

Yeah.
Nothing is simple, and really depend on personal opinion. And maybe even harder to categorized from submission info (often near zero context, and a glance at the project README is not always enough).

I guess need vs help can be defined as: "If you remove it and the application still work, it's help". But yet again, hard to deduce without a "test rig" (which is impossible to create as every package have different setup, effect, etc.)

lachlancollins commented

The need vs help difference sounds like a pretty difficult line to draw. I would be surprised that vite plugins and preprocessors are on one page, but HMR plugins and prettier plugins are on a different page.

I agree with this - I would suggest defining it as "things you add to package.json", which is fairly straightforward and easy to deduce from a README. I've submitted a PR for this proposal at #533 - please let me know if you have any thoughts!