From f901efb45d2816fa62453802b7e8a789d8379264 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Kevin=20=C3=85berg=20Kultalahti?= Date: Fri, 12 Jun 2020 19:54:07 +0200 Subject: [PATCH 1/5] Create 0000-built-in-actions.md --- text/0000-built-in-actions.md | 58 +++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 text/0000-built-in-actions.md diff --git a/text/0000-built-in-actions.md b/text/0000-built-in-actions.md new file mode 100644 index 0000000..31a2543 --- /dev/null +++ b/text/0000-built-in-actions.md @@ -0,0 +1,58 @@ +- Start Date: (fill me in with today's date, YYYY-MM-DD) +- RFC PR: (leave this empty) +- Svelte Issue: (leave this empty) + +# Built-in Actions + +## Summary + +This RFC proposes the idea of having a number of common built-in actions much like there +are built-in transitions. + +## Motivation + +Actions are currently a bit of a mystery to a lot of people but are incredibly powerful. +Having a number of ready-made actions would increase the simpleness of getting started +and adds ease-of-use to beginners of Svelte. + +This is one of those things that blows minds when they first see it, much like the +transitions. It would greatly ease efforts to market Svelte as *the* framework that +people should use. + +## Detailed design + +Much like the `svelte/transition` package a `svelte/action` package could be created. +You would import them like so: `import { longPress } from 'svelte/action'`. +In here we would put whatever actions that would make sense to put here. These +could be actions such as `use:longpress`, `use:clickOutside`, `use:lazyload` and so on. +Determining what actions should and should not be included needs to be discussed. + +## How we teach this + +> What names and terminology work best for these concepts and why? How is this +idea best presented? As a continuation of existing Svelte patterns, or as a +wholly new one? + +There are no real new concepts added by this RFC but I can see how we would probably want +to add one or two new Tutorials and Examples. The documentation would need to be expanded +a bit to also show off these actions, much like how transitions are described there. + +## Drawbacks + +The first one is documentaiton. This would probably require the most work in the short-term +but I think it would be a pretty straight-forward thing once the actual actions that are +included are decided. + +The other downside is that the amount of code to maintain increases. We would have to update +and keep these actions working but unless the syntax changes radically or the concept of +actions is going away (😡) I think it might be worth it. + +## Alternatives + +There are probably not any other alternatives to this, apart from not doing it. + + +## Unresolved questions + +The obvious question here would be to decide what actions should be included. What are some +popular use-cases that would fit well here? From cd5e04d01e92e876a3c2abfb266b4263a63c7e6c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Kevin=20=C3=85berg=20Kultalahti?= Date: Fri, 12 Jun 2020 19:57:42 +0200 Subject: [PATCH 2/5] remove cruft --- text/0000-built-in-actions.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/text/0000-built-in-actions.md b/text/0000-built-in-actions.md index 31a2543..a57e67d 100644 --- a/text/0000-built-in-actions.md +++ b/text/0000-built-in-actions.md @@ -29,10 +29,6 @@ Determining what actions should and should not be included needs to be discussed ## How we teach this -> What names and terminology work best for these concepts and why? How is this -idea best presented? As a continuation of existing Svelte patterns, or as a -wholly new one? - There are no real new concepts added by this RFC but I can see how we would probably want to add one or two new Tutorials and Examples. The documentation would need to be expanded a bit to also show off these actions, much like how transitions are described there. From 9a06bf0fe337388e963998746e33be456a7c1a97 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Kevin=20=C3=85berg=20Kultalahti?= Date: Fri, 12 Jun 2020 19:59:50 +0200 Subject: [PATCH 3/5] add date --- text/0000-built-in-actions.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/text/0000-built-in-actions.md b/text/0000-built-in-actions.md index a57e67d..1bf5819 100644 --- a/text/0000-built-in-actions.md +++ b/text/0000-built-in-actions.md @@ -1,6 +1,6 @@ -- Start Date: (fill me in with today's date, YYYY-MM-DD) -- RFC PR: (leave this empty) -- Svelte Issue: (leave this empty) +- Start Date: 2020-06-12 +- RFC PR: +- Svelte Issue: # Built-in Actions From bcd0e49b2fc4f2b78b22677fa733384c93e89159 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Kevin=20=C3=85berg=20Kultalahti?= Date: Fri, 12 Jun 2020 20:02:05 +0200 Subject: [PATCH 4/5] re-work list of actions --- text/0000-built-in-actions.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/text/0000-built-in-actions.md b/text/0000-built-in-actions.md index 1bf5819..c424512 100644 --- a/text/0000-built-in-actions.md +++ b/text/0000-built-in-actions.md @@ -24,7 +24,13 @@ people should use. Much like the `svelte/transition` package a `svelte/action` package could be created. You would import them like so: `import { longPress } from 'svelte/action'`. In here we would put whatever actions that would make sense to put here. These -could be actions such as `use:longpress`, `use:clickOutside`, `use:lazyload` and so on. +could be actions such as: + +- `use:longpress` +- `use:clickOutside` +- `use:lazyload` +- `use:debugFlash` + Determining what actions should and should not be included needs to be discussed. ## How we teach this From 47b3799f6f3e4b08292020a0e78e27954868c078 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Kevin=20=C3=85berg=20Kultalahti?= Date: Fri, 12 Jun 2020 20:04:08 +0200 Subject: [PATCH 5/5] fix typo --- text/0000-built-in-actions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-built-in-actions.md b/text/0000-built-in-actions.md index c424512..d62ebf0 100644 --- a/text/0000-built-in-actions.md +++ b/text/0000-built-in-actions.md @@ -41,7 +41,7 @@ a bit to also show off these actions, much like how transitions are described th ## Drawbacks -The first one is documentaiton. This would probably require the most work in the short-term +The first one is documentation. This would probably require the most work in the short-term but I think it would be a pretty straight-forward thing once the actual actions that are included are decided.