From 1c03666647dc65a86a1c9042d73ccf26e245fc2c Mon Sep 17 00:00:00 2001
From: pushkin <pushkine.github@gmail.com>
Date: Sun, 13 Dec 2020 11:37:51 +0100
Subject: [PATCH 1/9] Create 0000-local-components.md

---
 text/0000-local-components.md | 88 +++++++++++++++++++++++++++++++++++
 1 file changed, 88 insertions(+)
 create mode 100644 text/0000-local-components.md

diff --git a/text/0000-local-components.md b/text/0000-local-components.md
new file mode 100644
index 0000000..59f03d8
--- /dev/null
+++ b/text/0000-local-components.md
@@ -0,0 +1,88 @@
+- Start Date: (fill me in with today's date, YYYY-MM-DD)
+- RFC PR: ([#44](https://github.com/sveltejs/rfcs/pull/44))
+- Svelte Issue: (leave this empty)
+
+# Local Components
+
+## Summary
+
+Allow `.svelte` files to define multiple Components
+
+## Motivation
+
+Each Component requires creating a brand new `.svelte` file, but sometimes a Component necessitates its own sub-Components, this happens in the following occasions :
+1. a node tree pattern is repeated several times 
+2. a node tree needs to be wrapped or not depending on a condition
+3. a node uses completely different attributes/directives depending on a condition
+4. a variable from a `let:` slot prop, an `#await` resolved promise or a `#each` value is transformed then used more than once
+5. an `#each` block needs its own script for `$`subscriptions or lifecycle
+
+Having to spread tiny parts of a Component across several files is unfortunate as it leads to duplicate component names, cluttered folders and quite the refactoring hazard
+
+To solve those, @Rich-Harris has put forth a collection of RFCS: 
+* #32 to allow nesting styles in node trees
+* #33 to allow declaring `const`s in node trees
+* #34 to allow declaring reusable node trees
+
+Now all of those combined barely make up for a pseudocomponent, yet they introduce and bend several concepts in the framework, and issue 5) would still require an external component
+
+**_Each one of our issues can be and are currently solved by making a new Component_**, we just don't like spreading them across several files
+
+## Detailed design
+
+A Svelte Component is composed of a script block, a style block and a node tree
+
+A `.svelte` file is composed of a script context module and a Svelte Component that becomes the default export
+
+```xml
+
+<script context="module"/>
+
+<script/>
+<style/>
+<content/>
+
+```
+
+The proposed design is simple: `.svelte` files may define named Svelte Components in series using a top-level Comment block. 
+
+```xml
+<script context="module">
+
+<script/>
+<style/>
+<content/>
+
+<!-- Foo -->
+<script/>
+<style/>
+<content/>
+
+<!-- Bar -->
+<script/>
+<style/>
+<content/>
+```
+Everything above the first named Component (if any) stays the default export.
+
+The `Foo` variable works exactly as if that file imported `import Foo from "./Foo.svelte"`, so `Foo` cannot access anything from the default Component,  it's all on its own with its own style, script and content.
+
+The only thing that is different from a conventional import is that `Foo` has access to the script module and can use the other named Components present in the file if any.
+
+
+## How we teach this
+
+This RFC does not introduce any kind of directive, special element or new concept. 
+
+If your component needs to be split into parts, just write it underneath.
+
+## Drawbacks
+
+Technically breaking
+
+## Unresolved questions
+
+* Is there something better than a Comment Node ? 
+* Should the comment node include a specific word to better describe its intent ? `<!-- declare Foo -->` 
+* Should local components be directly exportable ? `<!-- export Foo [as Bar] -->`
+* Given that each component scopes its style, should there be a `<style context="module">` shared across all components in the same file ?

From 0ce9631371ca1509d89cde7bb241468ead9bda35 Mon Sep 17 00:00:00 2001
From: pushkin <pushkine.github@gmail.com>
Date: Sun, 13 Dec 2020 11:39:42 +0100
Subject: [PATCH 2/9] Update 0000-local-components.md

---
 text/0000-local-components.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/text/0000-local-components.md b/text/0000-local-components.md
index 59f03d8..4b0bab4 100644
--- a/text/0000-local-components.md
+++ b/text/0000-local-components.md
@@ -1,4 +1,4 @@
-- Start Date: (fill me in with today's date, YYYY-MM-DD)
+- Start Date: 2020-12-13
 - RFC PR: ([#44](https://github.com/sveltejs/rfcs/pull/44))
 - Svelte Issue: (leave this empty)
 

From 41acdf6b100bd041f8d669db668bc541948d2fc0 Mon Sep 17 00:00:00 2001
From: pushkin <pushkine.github@gmail.com>
Date: Sun, 13 Dec 2020 12:02:45 +0100
Subject: [PATCH 3/9] Update 0000-local-components.md

---
 text/0000-local-components.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/text/0000-local-components.md b/text/0000-local-components.md
index 4b0bab4..0a01f49 100644
--- a/text/0000-local-components.md
+++ b/text/0000-local-components.md
@@ -85,4 +85,5 @@ Technically breaking
 * Is there something better than a Comment Node ? 
 * Should the comment node include a specific word to better describe its intent ? `<!-- declare Foo -->` 
 * Should local components be directly exportable ? `<!-- export Foo [as Bar] -->`
+* * If so, should they be named exports or static properties of the default export ? `Component.Foo`
 * Given that each component scopes its style, should there be a `<style context="module">` shared across all components in the same file ?

From d13e84509cb992a628f9cab5618907915fd0b24e Mon Sep 17 00:00:00 2001
From: pushkine <pushkine.github@gmail.com>
Date: Tue, 9 Feb 2021 14:41:53 +0100
Subject: [PATCH 4/9] Update 0000-local-components.md

---
 text/0000-local-components.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/text/0000-local-components.md b/text/0000-local-components.md
index 0a01f49..6814218 100644
--- a/text/0000-local-components.md
+++ b/text/0000-local-components.md
@@ -26,7 +26,7 @@ To solve those, @Rich-Harris has put forth a collection of RFCS:
 
 Now all of those combined barely make up for a pseudocomponent, yet they introduce and bend several concepts in the framework, and issue 5) would still require an external component
 
-**_Each one of our issues can be and are currently solved by making a new Component_**, we just don't like spreading them across several files
+**_Each of those issues can be and is currently solved by making a new Component_**, we just don't like spreading them across several files
 
 ## Detailed design
 

From d78f50fd1d24d14f469837d1926027baf0bc6ec2 Mon Sep 17 00:00:00 2001
From: pushkine <pushkine.github@gmail.com>
Date: Tue, 9 Feb 2021 14:42:22 +0100
Subject: [PATCH 5/9] Update 0000-local-components.md

---
 text/0000-local-components.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/text/0000-local-components.md b/text/0000-local-components.md
index 6814218..bf87379 100644
--- a/text/0000-local-components.md
+++ b/text/0000-local-components.md
@@ -26,7 +26,7 @@ To solve those, @Rich-Harris has put forth a collection of RFCS:
 
 Now all of those combined barely make up for a pseudocomponent, yet they introduce and bend several concepts in the framework, and issue 5) would still require an external component
 
-**_Each of those issues can be and is currently solved by making a new Component_**, we just don't like spreading them across several files
+**_Each of those issues can and is currently solved by making a new Component_**, we just don't like spreading them across several files
 
 ## Detailed design
 

From 144bfa25a3d4c9a17ddff4eca9c5cd572e8073b1 Mon Sep 17 00:00:00 2001
From: pushkine <pushkine.github@gmail.com>
Date: Tue, 9 Feb 2021 15:05:03 +0100
Subject: [PATCH 6/9] Update 0000-local-components.md

---
 text/0000-local-components.md | 19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/text/0000-local-components.md b/text/0000-local-components.md
index bf87379..73036e3 100644
--- a/text/0000-local-components.md
+++ b/text/0000-local-components.md
@@ -44,7 +44,7 @@ A `.svelte` file is composed of a script context module and a Svelte Component t
 
 ```
 
-The proposed design is simple: `.svelte` files may define named Svelte Components in series using a top-level Comment block. 
+The proposed design is simple: Allow `.svelte` files to define named Svelte Components in series using a top-level Comment block. 
 
 ```xml
 <script context="module">
@@ -65,25 +65,32 @@ The proposed design is simple: `.svelte` files may define named Svelte Component
 ```
 Everything above the first named Component (if any) stays the default export.
 
-The `Foo` variable works exactly as if that file imported `import Foo from "./Foo.svelte"`, so `Foo` cannot access anything from the default Component,  it's all on its own with its own style, script and content.
+The `Foo` variable works exactly as if that file imported `import Foo from "./Foo.svelte"`, `Foo` cannot access anything from the default Component,  it's all on its own with its own style, script and content.
 
-The only thing that is different from a conventional import is that `Foo` has access to the script module and can use the other named Components present in the file if any.
+The only thing difference from a conventional import is that `Foo` has access to the script module & can instantiate other named Components present in the file if any.
 
+The benefits of this design are multiple
+ * Incredibly simple and straightforward
+ * Doesn't add indentation
+ * Compatible with Typescript
+ * Easy to implement & maintain
+ * Doesn't introduce new concepts
+ * Doesn't fragment Component features
 
 ## How we teach this
 
 This RFC does not introduce any kind of directive, special element or new concept. 
 
-If your component needs to be split into parts, just write it underneath.
+If your component needs to be split into parts, just write it underneath!
 
 ## Drawbacks
 
-Technically breaking
+Someone out there could be using that Component declaration synthax for something else, so it is technically breaking.
 
 ## Unresolved questions
 
 * Is there something better than a Comment Node ? 
 * Should the comment node include a specific word to better describe its intent ? `<!-- declare Foo -->` 
 * Should local components be directly exportable ? `<!-- export Foo [as Bar] -->`
-* * If so, should they be named exports or static properties of the default export ? `Component.Foo`
+  * If so, should they be named exports or static properties of the default Component ? `Component.Foo`
 * Given that each component scopes its style, should there be a `<style context="module">` shared across all components in the same file ?

From 315d48c685cd915cb98a2562398b85fbfe95a864 Mon Sep 17 00:00:00 2001
From: pushkine <pushkine.github@gmail.com>
Date: Tue, 9 Feb 2021 15:13:37 +0100
Subject: [PATCH 7/9] Update 0000-local-components.md

---
 text/0000-local-components.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/text/0000-local-components.md b/text/0000-local-components.md
index 73036e3..a7112f5 100644
--- a/text/0000-local-components.md
+++ b/text/0000-local-components.md
@@ -16,6 +16,7 @@ Each Component requires creating a brand new `.svelte` file, but sometimes a Com
 3. a node uses completely different attributes/directives depending on a condition
 4. a variable from a `let:` slot prop, an `#await` resolved promise or a `#each` value is transformed then used more than once
 5. an `#each` block needs its own script for `$`subscriptions or lifecycle
+6. a Component is too large and requires to be broken down for readability sake
 
 Having to spread tiny parts of a Component across several files is unfortunate as it leads to duplicate component names, cluttered folders and quite the refactoring hazard
 

From af5ffdb3b6500185c7f29662bae2c9e73b74b4c5 Mon Sep 17 00:00:00 2001
From: pushkine <pushkine.github@gmail.com>
Date: Tue, 9 Feb 2021 15:14:16 +0100
Subject: [PATCH 8/9] Update 0000-local-components.md

---
 text/0000-local-components.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/text/0000-local-components.md b/text/0000-local-components.md
index a7112f5..1dd5189 100644
--- a/text/0000-local-components.md
+++ b/text/0000-local-components.md
@@ -70,7 +70,7 @@ The `Foo` variable works exactly as if that file imported `import Foo from "./Fo
 
 The only thing difference from a conventional import is that `Foo` has access to the script module & can instantiate other named Components present in the file if any.
 
-The benefits of this design are multiple
+There's many benefits to this approach :
  * Incredibly simple and straightforward
  * Doesn't add indentation
  * Compatible with Typescript

From 621d189cf314dce068bfeea30b0b3107afbca012 Mon Sep 17 00:00:00 2001
From: pushkine <pushkine.github@gmail.com>
Date: Fri, 4 Jun 2021 15:35:21 +0200
Subject: [PATCH 9/9] Update 0000-local-components.md

---
 text/0000-local-components.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/text/0000-local-components.md b/text/0000-local-components.md
index 1dd5189..b8c2c13 100644
--- a/text/0000-local-components.md
+++ b/text/0000-local-components.md
@@ -68,7 +68,7 @@ Everything above the first named Component (if any) stays the default export.
 
 The `Foo` variable works exactly as if that file imported `import Foo from "./Foo.svelte"`, `Foo` cannot access anything from the default Component,  it's all on its own with its own style, script and content.
 
-The only thing difference from a conventional import is that `Foo` has access to the script module & can instantiate other named Components present in the file if any.
+The only difference from a conventional import is that `Foo` has access to the script module & can instantiate other named Components present in the file if any.
 
 There's many benefits to this approach :
  * Incredibly simple and straightforward