Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Local Components #44

Open
wants to merge 9 commits into
base: master
Choose a base branch
from
Open

Local Components #44

wants to merge 9 commits into from

Conversation

pushkine
Copy link

@pushkine pushkine commented Dec 13, 2020

Click here to read the RFC
please do not comment hot takes unless you've read the RFC 😄, below is just a TL;DR

Components often require their own private building blocks,
unfortunately in Svelte you must create a new file to declare a component.

This RFC proposes for .svelte files to define named components after the default export
defining a local component is done at the top level through a non-indentating syntax such as <!-- LocalComponentName -->

Eq0gHiPW8AEom8T

@Monkatraz
Copy link

Monkatraz commented Dec 13, 2020

A bit of syntax that Svelte sorta has already (and that isn't easily found in the documentation) is this:

<!-- @component JSDoc-esque component documentation can go here. -->
<script/>
<style/>
<content/>

More to the point, I think using a comment is a bit... vague? I feel like it could cause edge cases. Instead, I would prefer something like this:

{@component foo}
<script/>
<style/>
<content/>

This keeps the intuition of the @component token for documentation comments.

Alternatively, you could use the proposed <svelte:template> syntax and instead nest the local component inside of a tag rather than using a comment or {...} mechanism. Doing this does very rapidly approaches the original inline components RFC, and nullifies the technically simpler concept behind this RFC, but still.

Copy link

@stshepana-eng stshepana-eng left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Scho

@Crisfole
Copy link

Crisfole commented Mar 19, 2021

I was coming to find out if someone had an idea like this. I agree with the reasoning, even if I'm not 100% convinced it's strictly needed. It could make demos more concise too. I dislike using comments semantically, though I think we already have a solution built in, just need to repurpose it:

<script context="module">/* ... */</script>

<!-- This is a component accessible as <Foo> _inside_ this file only -->
<svelte:component name=Foo><!-- ... --></svelte:component>

<!-- This is a component accessible as <Bar> _inside_ this file only. It is exported by name as well. -->
<svelte:component export name=Bar><!-- ... --></svelte:component>

<!-- Any other content _outside_ the svelte:component remains the default export -->
<script>
  // Blah blah.
</script>

<Foo /> <!-- Didn't need to be imported since it's defined in-file -->
<Bar /> <!-- Didn't need to be imported since it's defined in-file -->

If you have an exported svelte:component the default export is optional.

@pepa-linha
Copy link

One file, one component. It is simple, clean and prepare to reusable.

@samclaus
Copy link

Yeah I caught myself thinking about small one-off modal templates today and wondering if frameworks (not just Svelte) should support inline/local components. Then I stopped myself.

  1. The "exportability" concept has a smell. If you're just gonna export them anyways, may as well give them their own file the old-fashioned way.
  2. Small, one-off things have a tendency to grow into bigger, needs-to-be-reusable things (in my experience).
  3. I write Angular on the job and the only reason I've ever preferred templates over full-fledged components was because Angular components ALWAYS wrap their markup in a host element at runtime, so you cannot have recursive components that produce a flat DOM list, etc. Svelte components do not have this problem to start with.

Honestly this one seems like an antifeature to me, unless people can provide several examples where it's really useful. Seems like it would take quite a bit of work to implement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants