From 316953e86f9c4ec05a5831358b2565aae83d5c65 Mon Sep 17 00:00:00 2001 From: peterkogo Date: Tue, 9 Jan 2024 15:19:57 +0100 Subject: [PATCH 1/7] add disable-unknown-prop-warnings rfc --- text/0000-disable-unknown-prop-warnings.md | 159 +++++++++++++++++++++ 1 file changed, 159 insertions(+) create mode 100644 text/0000-disable-unknown-prop-warnings.md diff --git a/text/0000-disable-unknown-prop-warnings.md b/text/0000-disable-unknown-prop-warnings.md new file mode 100644 index 0000000..79dbea5 --- /dev/null +++ b/text/0000-disable-unknown-prop-warnings.md @@ -0,0 +1,159 @@ +- Start Date: 2024-01-09 +- RFC PR: +- Svelte Issue: + +# A way to disable unknown prop warnings + +## Summary + +Make it possible to disable unknown prop warnings on a per component basis using + +```svelte + +``` + +## Motivation + +> Why are we doing this? What use cases does it support? + +> Please provide specific examples. If you say "this would be more flexible" then +> give an example of something that becomes easier. If you say "this would be make +> it easier to do X" then give an example of what that looks like today and what's +> hard about it. + +> Don't assume that others recognize the problem is one that needs to be solved +> Is there some concrete issue you cannot accomplish without this? +> What does it look like to accomplish some set of goals today and how could +> that be improved? +> Are there any workarounds that are necessary today? +> Are there open issues on Github where people would be helped by this? +> Will the change have performance impacts? Can you quantify them? + +> Please focus on explaining the motivation so that if this RFC is not accepted, +> the motivation could be used to develop alternative solutions. In other words, +> enumerate the constraints you are trying to solve without coupling them too +> closely to the solution you have in mind. + +When a parent component renders a child component with props that are not present on the child component + +```svelte +// Parent.svelte + + + +``` + +```svelte +// Child.svelte + + +

{foo}

+``` + +a warning is printed to the console + +```console + was created with unknown prop 'bar' +``` + +This is a sensible default behaviour in most cases and this RFC does not intend to change any of this. + +However, it poses issues for libraries that allow users to provide components that will be mounted by a library. +Take for example our use case at [svelte flow](https://svelteflow.dev/), a library that renders flowgraphs. With our architecture it is possible to mount any user provided Svelte components as either nodes or edges. These nodes receive information about their current state (which is managed by our library) over a number of props (its position, its label, if its it selected or not ...). Depending of the use case of the user it is not mandotory to implment all of these props, some are only needed in special situations. + +So in case we want to render 10 custom node components, where the component only uses 5 of the 10 possible props, the browser console is flooded by 50 unknown prop warnings. + +This issue [has already been discussed here](https://github.com/sveltejs/svelte/issues/5892#issuecomment-762660755). + +AFAIK the only workaround for this is to actually implement all props, and use them to prevent further unused prop warnings. + +```svelte +// Child.svelte + + +

{foo}

+``` + +Here is [a more extreme example of this.](https://svelteflow.dev/learn/guides/custom-nodes#suppress-unknown-prop-warnings) + +## Detailed design + +### Technical Background + +> There are a lot of ways Svelte is used. It's hosted on different platforms; +> integrated with different libraries; built with different bundlers, etc. No one +> person knows everything about all the ways Svelte is used. What does someone who +> knows about Svelte but hasn't necessarily used anything outside of it need to +> know? Are there docs you can share? + +> How do different libraries or frameworks implement this feature? We can take +> design inspiration from others who have done this well and improve upon the +> designs or make them better fit Svelte. + +`` already exists as way to communicate certain per component configurations to the compiler. + +### Implementation + +> Explain the design in enough detail for somebody familiar with the framework to +> understand, and for somebody familiar with the implementation to implement. Any +> new terminology should be defined here. + +> Explain not just the final design, but also how you arrived at it. What +> constraints did you face? Are there corner cases you've come up with solutions for? + +> Explain how your design fits into the larger picture. Are the other open problems +> in this area you're familiar with? How does this design fit with potential +> solutions for those issues? + +> Connect your design to the motivations you listed above. When describing a part of +> the design, it can be useful to share an example of what it would look like to +> utilize the implementation as solution to the problem. + +The idea of this RFC is to have the possibility to set this at the top of a component: + +```svelte + +``` + +which surpresses all unknown prop warnings. +As already discussed, having unknown prop warnings as a default is sensible, disabling it globally would defeat its purpose, thus having a way to opt-in on specific components that are expected to have unknown props seems like a good way forward. + +## 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? + +> Would the acceptance of this proposal mean the Svelte guides must be +> re-organized or altered? Does it change how Svelte is taught to new users +> at any level? + +> How should this feature be introduced and taught to existing Svelte +> users? + +## Drawbacks + +> Why should we _not_ do this? Please consider the impact on teaching Svelte, +> on the integration of this feature with other existing and planned features, +> on the impact of the API churn on existing apps, etc. + +> There are tradeoffs to choosing any path, please attempt to identify them here. + +## Alternatives + +> What other designs have been considered? What is the impact of not doing this? + +> This section could also include prior art, that is, how other frameworks in the +> same domain have solved this problem differently. + +## Unresolved questions + +> Optional, but suggested for first drafts. What parts of the design are still TBD? From f9e46b6b9cfae2509b9ebb6687d04410ee31412a Mon Sep 17 00:00:00 2001 From: peterkogo Date: Tue, 9 Jan 2024 15:22:49 +0100 Subject: [PATCH 2/7] fixed types --- text/0000-disable-unknown-prop-warnings.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-disable-unknown-prop-warnings.md b/text/0000-disable-unknown-prop-warnings.md index 79dbea5..ca73b9a 100644 --- a/text/0000-disable-unknown-prop-warnings.md +++ b/text/0000-disable-unknown-prop-warnings.md @@ -63,7 +63,7 @@ a warning is printed to the console This is a sensible default behaviour in most cases and this RFC does not intend to change any of this. However, it poses issues for libraries that allow users to provide components that will be mounted by a library. -Take for example our use case at [svelte flow](https://svelteflow.dev/), a library that renders flowgraphs. With our architecture it is possible to mount any user provided Svelte components as either nodes or edges. These nodes receive information about their current state (which is managed by our library) over a number of props (its position, its label, if its it selected or not ...). Depending of the use case of the user it is not mandotory to implment all of these props, some are only needed in special situations. +Take for example our use case at [svelte flow](https://svelteflow.dev/), a library that renders flowgraphs. With our architecture it is possible to mount any user provided Svelte component as either a node or an edge. Such nodes receive information (which is managed by our library) about their current state in the flow (its position, its label, if its it selected or not ...) over a number of props. Depending on the use case it is not mandotory to implment all of these props - some are only needed in special situations. So in case we want to render 10 custom node components, where the component only uses 5 of the 10 possible props, the browser console is flooded by 50 unknown prop warnings. From 6ad19021d7de0ac909bb2c9107a97497826838e9 Mon Sep 17 00:00:00 2001 From: John Robb Date: Tue, 9 Jan 2024 16:21:10 +0100 Subject: [PATCH 3/7] Update 0000-disable-unknown-prop-warnings.md --- text/0000-disable-unknown-prop-warnings.md | 94 ++++------------------ 1 file changed, 16 insertions(+), 78 deletions(-) diff --git a/text/0000-disable-unknown-prop-warnings.md b/text/0000-disable-unknown-prop-warnings.md index ca73b9a..44ef54b 100644 --- a/text/0000-disable-unknown-prop-warnings.md +++ b/text/0000-disable-unknown-prop-warnings.md @@ -9,32 +9,12 @@ Make it possible to disable unknown prop warnings on a per component basis using ```svelte - + ``` ## Motivation -> Why are we doing this? What use cases does it support? - -> Please provide specific examples. If you say "this would be more flexible" then -> give an example of something that becomes easier. If you say "this would be make -> it easier to do X" then give an example of what that looks like today and what's -> hard about it. - -> Don't assume that others recognize the problem is one that needs to be solved -> Is there some concrete issue you cannot accomplish without this? -> What does it look like to accomplish some set of goals today and how could -> that be improved? -> Are there any workarounds that are necessary today? -> Are there open issues on Github where people would be helped by this? -> Will the change have performance impacts? Can you quantify them? - -> Please focus on explaining the motivation so that if this RFC is not accepted, -> the motivation could be used to develop alternative solutions. In other words, -> enumerate the constraints you are trying to solve without coupling them too -> closely to the solution you have in mind. - -When a parent component renders a child component with props that are not present on the child component +As of now, when a parent component renders a child component with props that are not present on the child component ```svelte // Parent.svelte @@ -62,10 +42,9 @@ a warning is printed to the console This is a sensible default behaviour in most cases and this RFC does not intend to change any of this. -However, it poses issues for libraries that allow users to provide components that will be mounted by a library. -Take for example our use case at [svelte flow](https://svelteflow.dev/), a library that renders flowgraphs. With our architecture it is possible to mount any user provided Svelte component as either a node or an edge. Such nodes receive information (which is managed by our library) about their current state in the flow (its position, its label, if its it selected or not ...) over a number of props. Depending on the use case it is not mandotory to implment all of these props - some are only needed in special situations. +Take for example our use case at [svelte flow](https://svelteflow.dev/) (a library that renders flowgraphs). With our current architecture, it's possible to mount any user-provided Svelte component as a node. These nodes receive information (which is managed by svelte flow) about their current state with props (its position in the flow, its label, if it's selected or not, etc.). It is not mandatory for a user-provided custom component to implement all of these props - some are only needed in special situations. -So in case we want to render 10 custom node components, where the component only uses 5 of the 10 possible props, the browser console is flooded by 50 unknown prop warnings. +For example, if we want to render 10 custom node components in svelte flow, where the user-provided child component only implements 5 of the 10 possible passed props, the browser console will be flooded by 50 unknown prop warnings. This issue [has already been discussed here](https://github.com/sveltejs/svelte/issues/5892#issuecomment-762660755). @@ -82,78 +61,37 @@ bar; // this statement prevents unused prop warnings

{foo}

``` -Here is [a more extreme example of this.](https://svelteflow.dev/learn/guides/custom-nodes#suppress-unknown-prop-warnings) +Here is [a more extreme example in the svelte flow documentation.](https://svelteflow.dev/learn/guides/custom-nodes#suppress-unknown-prop-warnings) ## Detailed design ### Technical Background -> There are a lot of ways Svelte is used. It's hosted on different platforms; -> integrated with different libraries; built with different bundlers, etc. No one -> person knows everything about all the ways Svelte is used. What does someone who -> knows about Svelte but hasn't necessarily used anything outside of it need to -> know? Are there docs you can share? - -> How do different libraries or frameworks implement this feature? We can take -> design inspiration from others who have done this well and improve upon the -> designs or make them better fit Svelte. - `` already exists as way to communicate certain per component configurations to the compiler. ### Implementation -> Explain the design in enough detail for somebody familiar with the framework to -> understand, and for somebody familiar with the implementation to implement. Any -> new terminology should be defined here. - -> Explain not just the final design, but also how you arrived at it. What -> constraints did you face? Are there corner cases you've come up with solutions for? - -> Explain how your design fits into the larger picture. Are the other open problems -> in this area you're familiar with? How does this design fit with potential -> solutions for those issues? - -> Connect your design to the motivations you listed above. When describing a part of -> the design, it can be useful to share an example of what it would look like to -> utilize the implementation as solution to the problem. +- [] Should the parent do it? (peter) The idea of this RFC is to have the possibility to set this at the top of a component: ```svelte - + ``` -which surpresses all unknown prop warnings. -As already discussed, having unknown prop warnings as a default is sensible, disabling it globally would defeat its purpose, thus having a way to opt-in on specific components that are expected to have unknown props seems like a good way forward. - -## How we teach this +which suppresses all unknown prop warnings. -> 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? - -> Would the acceptance of this proposal mean the Svelte guides must be -> re-organized or altered? Does it change how Svelte is taught to new users -> at any level? - -> How should this feature be introduced and taught to existing Svelte -> users? - -## Drawbacks - -> Why should we _not_ do this? Please consider the impact on teaching Svelte, -> on the integration of this feature with other existing and planned features, -> on the impact of the API churn on existing apps, etc. - -> There are tradeoffs to choosing any path, please attempt to identify them here. +As already discussed, having unknown prop warnings as a default is sensible, but disabling it globally would defeat its purpose. Having a way to opt-in on specific components (ones that are expected to have unknown props) would be a good way forward. ## Alternatives -> What other designs have been considered? What is the impact of not doing this? +Two other possible names for this option include: -> This section could also include prior art, that is, how other frameworks in the -> same domain have solved this problem differently. +```svelte + +``` -## Unresolved questions +```svelte + +``` -> Optional, but suggested for first drafts. What parts of the design are still TBD? From 089171e073088b516492ff679b4074d44b991598 Mon Sep 17 00:00:00 2001 From: peterkogo Date: Tue, 9 Jan 2024 16:44:04 +0100 Subject: [PATCH 4/7] added unresolved questions --- text/0000-disable-unknown-prop-warnings.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/text/0000-disable-unknown-prop-warnings.md b/text/0000-disable-unknown-prop-warnings.md index 44ef54b..53d23cb 100644 --- a/text/0000-disable-unknown-prop-warnings.md +++ b/text/0000-disable-unknown-prop-warnings.md @@ -22,7 +22,7 @@ As of now, when a parent component renders a child component with props that are import Child from './Child.svelte' - + ``` ```svelte @@ -71,8 +71,6 @@ Here is [a more extreme example in the svelte flow documentation.](https://svelt ### Implementation -- [] Should the parent do it? (peter) - The idea of this RFC is to have the possibility to set this at the top of a component: ```svelte @@ -95,3 +93,9 @@ Two other possible names for this option include: ``` +## Unresolved Questions + +In genral, the goal of the warning is to raise awareness to improper usage of child components. However, the motivation for this change stems from a architectural design, where the parent component acts as a black box and the control of the user is acted out inside of child components. +This raises the question where to silence the prop warnings? Does the parent silence the prop warnings (parent accepts unproper usage of child components) or does the child silence them(child accepts unproper calls by parent component)? + +I prefer the former. From 54053e5a9fe36232b392982ceeb4481d806d4c1f Mon Sep 17 00:00:00 2001 From: peterkogo Date: Tue, 9 Jan 2024 16:58:02 +0100 Subject: [PATCH 5/7] added some additional info --- text/0000-disable-unknown-prop-warnings.md | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/text/0000-disable-unknown-prop-warnings.md b/text/0000-disable-unknown-prop-warnings.md index 53d23cb..12d098e 100644 --- a/text/0000-disable-unknown-prop-warnings.md +++ b/text/0000-disable-unknown-prop-warnings.md @@ -77,7 +77,11 @@ The idea of this RFC is to have the possibility to set this at the top of a comp ``` -which suppresses all unknown prop warnings. +which suppresses all unknown prop warnings for possibly unsound calls to children. + +Concerning the question: where should prop warnings be silenced? Should the parent silence prop warnings (parent accepts improper use of child components) or should the child silence them(child accepts unproper calls by parent component)? + +To keep the goal of the unknown prop warning, which is to raise awareness to the improper usage of child components, the proposed option should be provided to the parent component. As already discussed, having unknown prop warnings as a default is sensible, but disabling it globally would defeat its purpose. Having a way to opt-in on specific components (ones that are expected to have unknown props) would be a good way forward. @@ -92,10 +96,3 @@ Two other possible names for this option include: ```svelte ``` - -## Unresolved Questions - -In genral, the goal of the warning is to raise awareness to improper usage of child components. However, the motivation for this change stems from a architectural design, where the parent component acts as a black box and the control of the user is acted out inside of child components. -This raises the question where to silence the prop warnings? Does the parent silence the prop warnings (parent accepts unproper usage of child components) or does the child silence them(child accepts unproper calls by parent component)? - -I prefer the former. From bba8c3c989c1b92747a5c2d843baa69b3a4ef177 Mon Sep 17 00:00:00 2001 From: peterkogo Date: Tue, 9 Jan 2024 17:04:53 +0100 Subject: [PATCH 6/7] renamed proposal --- ...prop-warnings.md => 0000-silence-unknown-prop-warnings.md} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename text/{0000-disable-unknown-prop-warnings.md => 0000-silence-unknown-prop-warnings.md} (96%) diff --git a/text/0000-disable-unknown-prop-warnings.md b/text/0000-silence-unknown-prop-warnings.md similarity index 96% rename from text/0000-disable-unknown-prop-warnings.md rename to text/0000-silence-unknown-prop-warnings.md index 12d098e..c1d0d35 100644 --- a/text/0000-disable-unknown-prop-warnings.md +++ b/text/0000-silence-unknown-prop-warnings.md @@ -2,11 +2,11 @@ - RFC PR: - Svelte Issue: -# A way to disable unknown prop warnings +# Silence unknown prop warnings ## Summary -Make it possible to disable unknown prop warnings on a per component basis using +Make it possible to silence unknown prop warnings on a per component basis using ```svelte From 1655227371e2e2008c2cb62ab037806f3555c453 Mon Sep 17 00:00:00 2001 From: peterkogo <7165378+peterkogo@users.noreply.github.com> Date: Tue, 9 Jan 2024 20:20:06 +0100 Subject: [PATCH 7/7] fixed typos --- text/0000-silence-unknown-prop-warnings.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/text/0000-silence-unknown-prop-warnings.md b/text/0000-silence-unknown-prop-warnings.md index c1d0d35..8f39c40 100644 --- a/text/0000-silence-unknown-prop-warnings.md +++ b/text/0000-silence-unknown-prop-warnings.md @@ -42,7 +42,7 @@ a warning is printed to the console This is a sensible default behaviour in most cases and this RFC does not intend to change any of this. -Take for example our use case at [svelte flow](https://svelteflow.dev/) (a library that renders flowgraphs). With our current architecture, it's possible to mount any user-provided Svelte component as a node. These nodes receive information (which is managed by svelte flow) about their current state with props (its position in the flow, its label, if it's selected or not, etc.). It is not mandatory for a user-provided custom component to implement all of these props - some are only needed in special situations. +However, take for example our use case at [svelte flow](https://svelteflow.dev/) (a library that renders flowgraphs). With our current architecture, it's possible to mount any user-provided Svelte component as a node. These nodes receive information (which is managed by svelte flow) about their current state through props (its position in the flow, its label, if it's selected or not, etc.). It is not mandatory for a user-provided custom component to implement all of these props - some are only needed in special situations. For example, if we want to render 10 custom node components in svelte flow, where the user-provided child component only implements 5 of the 10 possible passed props, the browser console will be flooded by 50 unknown prop warnings. @@ -79,11 +79,11 @@ The idea of this RFC is to have the possibility to set this at the top of a comp which suppresses all unknown prop warnings for possibly unsound calls to children. -Concerning the question: where should prop warnings be silenced? Should the parent silence prop warnings (parent accepts improper use of child components) or should the child silence them(child accepts unproper calls by parent component)? +Concerning the question: where should prop warnings be silenced? Should the parent silence prop warnings (parent accepts improper use of child components) or should the child silence them (child accepts unproper calls by parent component)? -To keep the goal of the unknown prop warning, which is to raise awareness to the improper usage of child components, the proposed option should be provided to the parent component. +To keep in line with the original goal of the unknown prop warning, which is to raise awareness to the improper usage of child components, the proposed option should be provided inside the parent component. -As already discussed, having unknown prop warnings as a default is sensible, but disabling it globally would defeat its purpose. Having a way to opt-in on specific components (ones that are expected to have unknown props) would be a good way forward. +As already discussed, having unknown prop warnings as a default is sensible and disabling it globally would defeat its purpose. Having a way to opt-in on specific components (ones that are expected to have unknown props) would be a good way forward. ## Alternatives