Open lukaszkrzywizna opened 10 months ago
Hi there @lukaszkrzywizna sorry for the delayed response 🙏 been busy with day job, hard to keep track of everything going on in the OSS space.
About IReactProperty list
I really think of this as purely an interop mechanism when binding third-party components. If you are building your own components in pure F#, use normal parameters with [<ReactComponent>]
.
Using [<ReactListProperty>]
does sound interesting for niche use cases, in general I believe [<ReactComponent>]
should do the trick but i agree that ReactListProperty
is more flexible. To be honest I am a bit reluctant on adding more ways to implement these React components but I will think about it more
No problem @Zaid-Ajaj I know you're busy man :) I'll try to investigate it further in a free time and share something more.
Hi, First of all, I love Feliz! I very much like the paradigm it offers, especially the
IReactProperty list
approach. It's very readable and closest to the original JS/JSX approach.However, when I use it in conjunction with
ReactComponent
attribute I see one drawback - created react component instead of containing an object with props taken from the list, it has one single prop of a list type. In most cases it doesn't matter, but based on react-memo article text:we can assume that react somehow by checking what kind of props are passed.
Additionally, using traditional object param is more convenient when using React developer tools: For code
versus
The easiest solution is to manually translate
prop-list
into an object. However, I wonder if we could do something in the scope of Feliz.CompilerPlugin.I imagine that by using a special attribute (
ReactComponent
or something new), the plugin could detect if a function expects a single prop of a list type and map the input into an object by callingObject.fromEntries
and within the function unwrap it back by usingObject.entries
. #580 is a small POC that illustrates the solution:gives something similar to this
We can go further, and extend the existing tuple-component approach by allowing to put an extra list parameter that would be merged with the rest of the explicitly provided params (not implemented):
@Zaid-Ajaj I'd like to know your opinion about that. If you think that this makes sense, I can continue developing the solution. I'm open to any other option/approach.