Consolidate and expand children prop

[zaid-ajaj]

Consolidate and expand children prop

[Zaid-Ajaj]

I don't know for sure to be honest but I don't think it really matters considering how uncommon this construct is used (in my experience)

[zanaptak]

Regarding the first bullet point and by extension #23/#24/#25, text/innerText is a shortcut helper specifically for inserting text, not a general "insert a child node" helper. The internal API of the React children prop does not apply, this is about the Feliz consumer API as an adapter layer in this case. So distinguishing it from prop.children in some way seems appropriate, as does performing the standard string conversion on the parameter given the text name/intent of the helper.

[cmeeren]

and by extension #23/#24/#25

I read over them again to be sure, but as far as I can tell, they are orthogonal to this issue.

text/innerText is a shortcut helper specifically for inserting text, not a general "insert a child node" helper.

Please correct me if I'm wrong, but it seems that's in fact exactly what it does. Raw strings (and numbers) are valid React children, and Feliz is simply making a children prop with the input value (even though the documentation indicates otherwise).

Feliz/src/Properties.fs

Lines 59 to 60 in 51ec0c0

	/// Defines the text content of the element. Alias for `children [ Html.text value ]`
	static member inline text (value: string) = Interop.mkAttr "children" value

[Zaid-Ajaj]

@cmeeren

I don't think it is always good to strictly replicate the React API, in this case I chose for text instead of children because I find it making more sense and easier to think about when you look for things:

• "I need to change the text of the button => I will try to find a property that has the word 'text' in it" 😍
• "I have to set the children of an element where it will have one child of type text because React children also takes a string and happens to be compatible" 😒

even though the documentation indicates otherwise

How is that so? The docs are saying that this is just a shortcut for children [ Html.text value ] which ultimately results in the element having the content provided

[cmeeren]

Fair point :)

Re. the docs: You're right, the end result is the same.

I still suggest adding a string seq overload to prop.text, then, since AFAIK it may cause less re-renders than concatenating a string yourself and rendering that as a single node.

[Zaid-Ajaj]

I still suggest adding a string seq overload to prop.text, then, since AFAIK it may cause less re-renders than concatenating a string yourself and rendering that as a single node.

I don't it makes a lot of sense for prop.text to accept string seq. if you are reading through the overloads of prop.text and you see string seq, what would you think? Again in React primitives but who actually uses that and isn't that just a convenience helper to make JSX work properly? I would rather wait for a good use-case with examples to re-open the issue and implement it than trying to mimic the React API 1-to-1

[Zaid-Ajaj]

it may cause less re-renders

It won't cause less re-renders, it will save you the computation of concatenation (which React will do anyways)

[cmeeren]

IIRC the reason it will save re-renders is because React will re-use the already rendered nodes for unchanged strings. Can't remember where I picked that up, it's a long time ago... So I might misremember. Is it incorrect?