Make `<textarea>` a void element #3465

its-the-shrimp · 2023-10-13T18:17:59Z

Description

Fixes #3296 by raising an error when trying to provide children to <textarea> and asserting the correct way to provide default value to it in the docs, which is the defaultvalue attribute also added with this PR.
Documents the peculiarities of <textarea> and the void elements in general.

Checklist

I have reviewed my own code
I have added tests

github-actions · 2023-10-13T18:21:04Z

Visit the preview URL for this PR (updated for commit 66e8ad3):

https://yew-rs--pr3465-textarea2void-gtm0ku6i.web.app

_{(expires Mon, 30 Oct 2023 20:02:30 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

github-actions · 2023-10-13T18:25:57Z

Size Comparison

examples	master (KB)	pull request (KB)	diff (KB)	diff (%)
async_clock	102.908	103.111	+0.203	+0.197%
boids	175.774	175.980	+0.206	+0.117%
communication_child_to_parent	95.388	95.588	+0.200	+0.210%
communication_grandchild_with_grandparent	109.124	109.401	+0.277	+0.254%
communication_grandparent_to_grandchild	105.791	106.059	+0.268	+0.253%
communication_parent_to_child	92.864	93.068	+0.204	+0.220%
contexts	113.500	113.768	+0.268	+0.236%
counter	89.268	89.476	+0.208	+0.233%
counter_functional	90.005	90.206	+0.201	+0.224%
dyn_create_destroy_apps	92.440	92.642	+0.201	+0.218%
file_upload	103.600	103.801	+0.201	+0.194%
function_memory_game	174.675	174.881	+0.206	+0.118%
function_router	352.530	352.890	+0.359	+0.102%
function_todomvc	163.555	163.764	+0.209	+0.128%
futures	227.837	228.081	+0.244	+0.107%
game_of_life	112.282	112.483	+0.201	+0.179%
immutable	188.883	189.249	+0.366	+0.194%
inner_html	86.047	86.249	+0.202	+0.235%
js_callback	113.455	113.664	+0.209	+0.184%
keyed_list	201.029	201.229	+0.200	+0.100%
mount_point	89.269	89.478	+0.209	+0.234%
nested_list	115.902	116.094	+0.191	+0.165%
node_refs	96.365	96.566	+0.201	+0.209%
password_strength	1752.378	1752.579	+0.201	+0.011%
portals	98.466	98.733	+0.268	+0.272%
router	318.460	318.819	+0.359	+0.113%
simple_ssr	144.185	144.498	+0.313	+0.217%
ssr_router	390.318	390.656	+0.338	+0.087%
suspense	119.118	119.396	+0.278	+0.234%
timer	91.816	92.019	+0.202	+0.220%
timer_functional	100.520	100.722	+0.202	+0.201%
todomvc	143.861	144.070	+0.209	+0.145%
two_apps	89.977	90.178	+0.201	+0.224%
web_worker_fib	139.025	139.294	+0.269	+0.193%
web_worker_prime	190.481	190.877	+0.396	+0.208%
webgl	88.572	88.772	+0.200	+0.226%

✅ None of the examples has changed their size significantly.

github-actions · 2023-10-13T18:26:05Z

Benchmark - SSR

Yew Master

Benchmark	Round	Min (ms)	Max (ms)	Mean (ms)	Standard Deviation
Baseline	10	356.259	360.214	358.342	1.220
Hello World	10	617.614	621.970	618.595	1.736
Function Router	10	2103.588	2110.469	2107.901	2.268
Concurrent Task	10	1007.181	1008.852	1008.116	0.506
Many Providers	10	1467.052	1497.431	1478.223	10.437

Pull Request

Benchmark	Round	Min (ms)	Max (ms)	Mean (ms)	Standard Deviation
Baseline	10	319.270	321.213	319.621	0.573
Hello World	10	625.760	630.120	627.441	1.611
Function Router	10	2110.309	2126.143	2117.153	5.067
Concurrent Task	10	1007.520	1008.821	1008.317	0.411
Many Providers	10	1437.229	1465.041	1446.262	8.209

ranile · 2023-10-13T19:23:53Z

Why not recommend setting value? ~defaultValue works because defaultValue is a property on HTMLTextareaElement. Using value is how you should be interacting with the text area anyway. There's no point of having a textarea that you can't read from (technically, you can, with node refs but that is not the best way of doing things)

its-the-shrimp · 2023-10-13T19:47:35Z

We wouldn't recommend setting value because the MDN docs for <textarea> state explicitly that it doesn't work, and because children of <textarea> define not its value, but its default, initial value, which is exactly what setting ~defaultValue does as well.

ranile · 2023-10-13T20:15:02Z

The value attribute doesn't work on textarea but Yew has special handling for value for both input and textarea that makes it work (it makes value and ~value behave the same). If you want to listen to oninput on the text area and react to user input, you need to use the value property.

See this playground

its-the-shrimp · 2023-10-13T21:51:28Z

But the paragraph I've added to "html/elements" docs is specifically about the peculiarity of <textarea>: normally it accepts children, which define its defaultValue, but in Yew it's a void element and instead of children, ~defaultValue is provided, though value should indeed also be documented, I'll add that right now.

its-the-shrimp · 2023-10-13T21:54:55Z

Wait, why does <input>'s value need special handling if it already defines it?

ranile · 2023-10-13T21:56:20Z

Wait, why does <input>'s value need special handling if it already defines it?

The special handling predates the ~property syntax and controlled elements need it to be set as a property

its-the-shrimp · 2023-10-13T22:00:36Z

But then is it really special for <input>?

ranile · 2023-10-13T22:03:13Z

It's special because the value is always set as property, not attribute, for input

its-the-shrimp · 2023-10-13T22:24:39Z

Does that make a difference in case of <input>? I'm just wondering if it's worth it to explain all that in the docs or just pretend that <input> is a perfectly normal element

futursolo · 2023-10-14T01:23:24Z

Why not recommend setting value?

Setting a value makes an element controlled. An element with defaultvalue should remain uncontrolled.

But then is it really special for <input>?

Special handling for value and checked are required as these properties are controlled. This means that values are restored to the one provided to <input /> on every render regardless of whether a value is changed. The value displayed in an input is always in sync with the state associated with the value.
For other attributes, it only updates when an attribute is changed, added or removed.

futursolo · 2023-10-14T01:33:50Z

website/docs/concepts/html/elements.mdx

+Which would fail to compile, it's customary to write
+
+```html
+<textarea ~defaultValue="default value"></textarea>


Suggested change

<textarea ~defaultValue="default value"></textarea>

<textarea defaultvalue="default value" />

I am not in favour of promoting the property syntax for elements. It should only be reserved for cases where it is niche and should not / cannot be handled by the renderer (e.g.: custom elements). html! should work with built-in elements without users directly touching its properties.

I think we should make a special handing to assign defaultvalue (html! attribute) to value at the first time it is mounted.

I feel that there might be edge cases for ~defaultValue (property) when it is combined with Suspense as the element might be re-mounted.

And what would be the disadvantages to mimicking the actual HTML specification and make <textarea> accept children?

The childNodes for an HTMLTextAreaElement indicates its default value and not value.

Once the user starts to type in a textarea, normal means Yew uses to manipulate the DOM (e.g.: HTMLTextAreaElement.insertBefore) has no effect anymore. Manipulating childNodes does not reflect on the page.

Then we could, for example, not do anything with <textarea>'s children after it's inserted into the DOM, i.e. not reconcile it, which also might improve performance, besides, we already have special handling for <textarea>, it even has a separate variant for it in the VTagInner enum. It's just that going against the HTML spec would only unnecessarily complicate the framework from the perspective of the users, I believe that when it comes to HTML elements, we should strive to keep their usage in Yew as close to their actual definition in the standard as possible.

It's just that going against the HTML spec would only unnecessarily complicate the framework from the perspective of the users

The specification says that HtmlTextAreaElement's default value can be assigned via the defaultValue property. Since elements in Yew are created via document.createElement, we are not against the specification.

Specifically not reconciling textarea is only going to make users confused as it is not obvious to novice users that textarea is only defining its default value and value updates will need to be done via value attribute. It was also not obvious to me until after some previous discussion about making textarea to use children prop happened in the past.

This pull request makes it a compile error and suggests ~defaultValue to users, which is a better user experience IMO.

In addition, React and Vue both do not accept children for textarea. So we are consistent with the behaviour of major frameworks. This will ease the learning curve for users from these frameworks.

React: https://react.dev/reference/react-dom/components/textarea#props
Vue: https://vuejs.org/guide/essentials/forms.html#multiline-text

I'm curious about the use case where the textarea is needed and isn't controlled

examples/suspense/src/main.rs

packages/yew-macro/src/html_tree/html_element.rs

packages/yew-macro/tests/html_macro/element-fail.stderr

futursolo · 2023-10-21T04:47:19Z

packages/yew/src/virtual_dom/vtag.rs

+ .render()
+ .await;
+
+ assert_eq!(s, r#"<textarea value="teststring"></textarea>"#);


Suggested change

assert_eq!(s, r#"<textarea value="teststring"></textarea>"#);

assert_eq!(s, r#"<textarea>teststring</textarea>"#);

Since we are rendering this as HTML, <textarea> does not accept value attribute.

If both value and default value are set, the value prop should have priority and the defaultvalue prop should have no effect.

How do we provide the value during SSR then? In CSR we manipulate the element directly for that

I have submitted a review suggestion below, which should be cover both defaultvalue and value.

The component only gets 1 chance to declare HTML, which should match the initial render of CSR.

When both defaultvalue and value are set in CSR, default value never shows and value is shown instead, as value is set.
SSR should match this behaviour.

In practice, it doesn't make sense to set both default value and value as the defaultvalue is never shown.

If both are set, we should console.warn and lint in the macro. The lint can be in a future PR but I would like to have the console.warn with this PR

We might not be able to create a lint on the macro level.

One can create a component library and it would make sense for them to passthrough both value and defaultvalue.

packages/yew/tests/hydration.rs

packages/yew/src/virtual_dom/vtag.rs

packages/yew/src/virtual_dom/vlist.rs

.gitignore

its-the-shrimp · 2023-10-22T21:11:51Z

There's definitely something wrong with the benchmarking CI action

futursolo

This should fix the SSR behaviour of textarea.

See above.

packages/yew/src/virtual_dom/vtag.rs

futursolo

There are some remaining style fixes.

Otherwise, LGTM.

packages/yew/tests/hydration.rs

packages/yew/tests/suspense.rs

Co-authored-by: Kaede Hoshikawa <[email protected]>

its-the-shrimp added 3 commits October 13, 2023 18:50

made <textarea> a void element

9a2a656

updated docs, fixed formatting

9b8cd23

fixed hydration test

8e2fd57

its-the-shrimp added 3 commits October 13, 2023 19:26

fixed heading in docs

75e2d0e

fixed suspense test

71555bd

fixed hydration tests again

b29a33d

futursolo reviewed Oct 14, 2023

View reviewed changes

its-the-shrimp added 4 commits October 18, 2023 21:40

added defaultvalue special attr to <textarea>

8a6cd8e

fix docs formatting

727f400

fixed clippy warnings

9ca375c

updated error message when trying to pass children to textarea

a6ca242

its-the-shrimp requested a review from futursolo October 19, 2023 16:31

futursolo reviewed Oct 22, 2023

View reviewed changes

its-the-shrimp added 3 commits October 22, 2023 19:26

fixes to error messages and formatting

1c39a1d

fixed formatting

0c747e6

fixed formatting

7e3769e

futursolo reviewed Oct 23, 2023

View reviewed changes

packages/yew/src/virtual_dom/vtag.rs Outdated Show resolved Hide resolved

packages/yew/src/virtual_dom/vtag.rs Outdated Show resolved Hide resolved

its-the-shrimp added 5 commits October 23, 2023 20:09

fixed SSR, added SSR test for precedence of value over defaultvalue

9eddf43

fixed hydration test

51c785b

fixed hydration test

a0ecff5

fixed hydration test

518d49a

fixed HTML formatting

66e8ad3

futursolo reviewed Oct 28, 2023

View reviewed changes

packages/yew/tests/hydration.rs Outdated Show resolved Hide resolved

packages/yew/tests/suspense.rs Outdated Show resolved Hide resolved

its-the-shrimp and others added 2 commits October 28, 2023 19:39

Fix HTML formatting

0b8183d

Co-authored-by: Kaede Hoshikawa <[email protected]>

Fix HTML formatting

28d4cec

Co-authored-by: Kaede Hoshikawa <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Make `<textarea>` a void element #3465

Make `<textarea>` a void element #3465

its-the-shrimp commented Oct 13, 2023 •

edited

Loading

github-actions bot commented Oct 13, 2023 •

edited

Loading

github-actions bot commented Oct 13, 2023 •

edited

Loading

github-actions bot commented Oct 13, 2023 •

edited

Loading

ranile commented Oct 13, 2023

its-the-shrimp commented Oct 13, 2023

ranile commented Oct 13, 2023

its-the-shrimp commented Oct 13, 2023

its-the-shrimp commented Oct 13, 2023

ranile commented Oct 13, 2023

its-the-shrimp commented Oct 13, 2023

ranile commented Oct 13, 2023

its-the-shrimp commented Oct 13, 2023 •

edited

Loading

futursolo commented Oct 14, 2023 •

edited

Loading

futursolo Oct 14, 2023 •

edited

Loading

its-the-shrimp Oct 14, 2023

futursolo Oct 15, 2023 •

edited

Loading

its-the-shrimp Oct 15, 2023

futursolo Oct 15, 2023 •

edited

Loading

ranile Oct 22, 2023

futursolo Oct 21, 2023

its-the-shrimp Oct 22, 2023

futursolo Oct 23, 2023

futursolo Oct 23, 2023

ranile Oct 23, 2023

futursolo Oct 23, 2023

its-the-shrimp commented Oct 22, 2023

futursolo left a comment

futursolo left a comment

	<textarea ~defaultValue="default value"></textarea>
	<textarea defaultvalue="default value" />

	assert_eq!(s, r#"<textarea value="teststring"></textarea>"#);
	assert_eq!(s, r#"<textarea>teststring</textarea>"#);

Make <textarea> a void element #3465

Are you sure you want to change the base?

Make <textarea> a void element #3465

Conversation

its-the-shrimp commented Oct 13, 2023 • edited Loading

Description

Checklist

github-actions bot commented Oct 13, 2023 • edited Loading

github-actions bot commented Oct 13, 2023 • edited Loading

Size Comparison

github-actions bot commented Oct 13, 2023 • edited Loading

Benchmark - SSR

Yew Master

Pull Request

ranile commented Oct 13, 2023

its-the-shrimp commented Oct 13, 2023

ranile commented Oct 13, 2023

its-the-shrimp commented Oct 13, 2023

its-the-shrimp commented Oct 13, 2023

ranile commented Oct 13, 2023

its-the-shrimp commented Oct 13, 2023

ranile commented Oct 13, 2023

its-the-shrimp commented Oct 13, 2023 • edited Loading

futursolo commented Oct 14, 2023 • edited Loading

futursolo Oct 14, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

futursolo Oct 15, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

futursolo Oct 15, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

its-the-shrimp commented Oct 22, 2023

futursolo left a comment

Choose a reason for hiding this comment

futursolo left a comment

Choose a reason for hiding this comment

Make `<textarea>` a void element #3465

Make `<textarea>` a void element #3465

its-the-shrimp commented Oct 13, 2023 •

edited

Loading

github-actions bot commented Oct 13, 2023 •

edited

Loading

github-actions bot commented Oct 13, 2023 •

edited

Loading

github-actions bot commented Oct 13, 2023 •

edited

Loading

its-the-shrimp commented Oct 13, 2023 •

edited

Loading

futursolo commented Oct 14, 2023 •

edited

Loading

futursolo Oct 14, 2023 •

edited

Loading

futursolo Oct 15, 2023 •

edited

Loading

futursolo Oct 15, 2023 •

edited

Loading