From 325e1a709d56bf7125bb2126627e5576be7f10ae Mon Sep 17 00:00:00 2001 From: Stas Lashmanov Date: Fri, 10 Jan 2020 21:24:24 +0300 Subject: [PATCH 1/5] Add RFC: Remove data object delcaration --- .../0000-remove-data-object-declaration.md | 78 +++++++++++++++++++ 1 file changed, 78 insertions(+) create mode 100644 active-rfcs/0000-remove-data-object-declaration.md diff --git a/active-rfcs/0000-remove-data-object-declaration.md b/active-rfcs/0000-remove-data-object-declaration.md new file mode 100644 index 00000000..f82c0e6d --- /dev/null +++ b/active-rfcs/0000-remove-data-object-declaration.md @@ -0,0 +1,78 @@ +- Start Date: 2020-01-10 +- Target Major Version: 3.x +- Implementation PR: (leave this empty) + +# Summary + +`data` component option accepts two types of declaration: `function` or `object`. The most common is the `function` declaration, because it creates a new state for each instance of the component. `object` declaration on the other hand shares state between all the component's instances. This RFC focuses on removing `object` declaration for `data`. + +# Motivation + +There are little or no use-cases for component's instances to have a shared state. Even if you encounter such a case it can be done using `function` declaration. +Having two types of declaration is not novice-friendly and is confusing without proper examples (which are nonexistent in the current documentation). +With a single type of declaration you could achieve the same results and eliminate the confusing part of it. + +# Detailed design + +`object` declaration should no longer be valid and produce an error with an explanation that only `function` declaration is valid for a component. It should also contain a link to an API and migration example. + +Before, using `object` declaration: + +```html + +``` + +After, using `function` declaration. + +```html + +``` + +`sharedObject` will be the same in each component's instance. + +# Drawbacks + +Users that work with `object` declaration would require migrating to `function` declaration. + +It would also not be possible to have top-level shared state. + +Examples using `object` declaration should be rewritten using `function` declaration. + +# Adoption strategy + +Since it's not a common pattern in components migration should be fairly easy. + +Migration itself is straightforward: + +* Extract shared data into an external object and use it as a property in `data`. +* Rewrite references to the shared data to point to a new shared object. + +API page should contain an info block that `object` declaration is deprecated with a guide on how to migrate. + +An adapter could be provided to retain backwards compatibility. From 92ef6057b2fbd396ce8e6138cc89f95efd9335ed Mon Sep 17 00:00:00 2001 From: Stanislav Lashmanov Date: Sat, 11 Jan 2020 02:39:26 +0300 Subject: [PATCH 2/5] Update to match the API --- .../0000-remove-data-object-declaration.md | 64 ++++++++++--------- 1 file changed, 33 insertions(+), 31 deletions(-) diff --git a/active-rfcs/0000-remove-data-object-declaration.md b/active-rfcs/0000-remove-data-object-declaration.md index f82c0e6d..a1b6f9f2 100644 --- a/active-rfcs/0000-remove-data-object-declaration.md +++ b/active-rfcs/0000-remove-data-object-declaration.md @@ -4,58 +4,60 @@ # Summary -`data` component option accepts two types of declaration: `function` or `object`. The most common is the `function` declaration, because it creates a new state for each instance of the component. `object` declaration on the other hand shares state between all the component's instances. This RFC focuses on removing `object` declaration for `data`. +`data` option accepts two types of declaration: `function` or `object`. The most common is the `function` declaration, because it creates a new state for each instance of the component. `object` declaration on the other hand shares state between all the instances and works only on a root instance. This RFC primarily focuses on removing `object` declaration for `data`. # Motivation -There are little or no use-cases for component's instances to have a shared state. Even if you encounter such a case it can be done using `function` declaration. -Having two types of declaration is not novice-friendly and is confusing without proper examples (which are nonexistent in the current documentation). -With a single type of declaration you could achieve the same results and eliminate the confusing part of it. +There are little or no use-cases for root instances to have a shared state. Even if you encounter such a case it can be achieved using `function` declaration. +Having two types of declaration is not novice-friendly and is confusing without proper examples (which are nonexistent in the current documentation). The additional restriction that `object` declaration is possible only on the root instance is also confusing. +With a unified declaration you could achieve the same result and eliminate the confusing part of it. # Detailed design -`object` declaration should no longer be valid and produce an error with an explanation that only `function` declaration is valid for a component. It should also contain a link to an API and migration example. +`object` declaration should no longer be valid and produce an error with an explanation that only `function` declaration is valid for `data` on the root instance. It should also contain a link to an API and migration example. Before, using `object` declaration: -```html - + render() { + return [ + h('span', this.counter), + h('button', { + onClick: () => { this.counter++ } + }), + ] + }, +}, '#app') ``` After, using `function` declaration. -```html - + render() { + return [ + h('span', this.counter), + h('button', { + onClick: () => { this.counter++ } + }), + ] + }, +}, '#app') ``` -`sharedObject` will be the same in each component's instance. - # Drawbacks Users that work with `object` declaration would require migrating to `function` declaration. @@ -66,7 +68,7 @@ Examples using `object` declaration should be rewritten using `function` declara # Adoption strategy -Since it's not a common pattern in components migration should be fairly easy. +Since it's not a common pattern to have an `object` declaration in root instance migration should be fairly easy. Migration itself is straightforward: From e815bf34c95905abc319113766c3df58f92f9b2f Mon Sep 17 00:00:00 2001 From: Stanislav Lashmanov Date: Sat, 11 Jan 2020 02:41:39 +0300 Subject: [PATCH 3/5] Typo --- active-rfcs/0000-remove-data-object-declaration.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/active-rfcs/0000-remove-data-object-declaration.md b/active-rfcs/0000-remove-data-object-declaration.md index a1b6f9f2..355bc347 100644 --- a/active-rfcs/0000-remove-data-object-declaration.md +++ b/active-rfcs/0000-remove-data-object-declaration.md @@ -75,6 +75,6 @@ Migration itself is straightforward: * Extract shared data into an external object and use it as a property in `data`. * Rewrite references to the shared data to point to a new shared object. -API page should contain an info block that `object` declaration is deprecated with a guide on how to migrate. +API page should contain an info block describing that `object` declaration is deprecated with a guide on how to migrate. An adapter could be provided to retain backwards compatibility. From de0e90b5b1b048d4c1bdd1eb61f9e896c6c469d8 Mon Sep 17 00:00:00 2001 From: Stanislav Lashmanov Date: Mon, 20 Jan 2020 22:51:12 +0300 Subject: [PATCH 4/5] Clarify migration impact --- active-rfcs/0000-remove-data-object-declaration.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/active-rfcs/0000-remove-data-object-declaration.md b/active-rfcs/0000-remove-data-object-declaration.md index 355bc347..97f7b8ec 100644 --- a/active-rfcs/0000-remove-data-object-declaration.md +++ b/active-rfcs/0000-remove-data-object-declaration.md @@ -68,7 +68,7 @@ Examples using `object` declaration should be rewritten using `function` declara # Adoption strategy -Since it's not a common pattern to have an `object` declaration in root instance migration should be fairly easy. +Since it's not a common pattern to have an `object` declaration in root instance migration should be fairly easy. The impact of this change is also minimized due to the root mounting API change in v3 (where you always use a root component). Migration itself is straightforward: From 8edd73ccf9975b889f20483fb12b2de16fc9c404 Mon Sep 17 00:00:00 2001 From: Evan You Date: Mon, 17 Feb 2020 11:40:19 -0500 Subject: [PATCH 5/5] Rename 0000-remove-data-object-declaration.md to 0019-remove-data-object-declaration.md --- ...ject-declaration.md => 0019-remove-data-object-declaration.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename active-rfcs/{0000-remove-data-object-declaration.md => 0019-remove-data-object-declaration.md} (100%) diff --git a/active-rfcs/0000-remove-data-object-declaration.md b/active-rfcs/0019-remove-data-object-declaration.md similarity index 100% rename from active-rfcs/0000-remove-data-object-declaration.md rename to active-rfcs/0019-remove-data-object-declaration.md