Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Destructuring "type parallelism" error in createElement #39

Open
potrykus opened this issue Oct 26, 2018 · 0 comments
Open

Destructuring "type parallelism" error in createElement #39

potrykus opened this issue Oct 26, 2018 · 0 comments

Comments

@potrykus
Copy link

return sel(data || {}, children)

If line 69 collects all ...children in an array (e.g. JSX.Element[]), shouldn't ...children be re-splatted into the sel fn on line 71?

As line 71 is now written, sel(, children) gets an extra level of array wrapping with each pass into a Component (at one pass deeper in, JSX.Element[] arrays become JSX.Element[][], with only the zeroth element populated). I believe this is not the intent.

Interestingly the story for sanitizeChildren called on line 73 is different and instructive: Pure text is only ever found through the zeroth element of the rhs OR operand on line 60, but this is different from what a general Component sel fn (line 71) expects I believe (that won't expect an [][]).

Last, line 77 is "saved" (meaning will have no apparent problems), I guess, by line 62's reduceDeep, right? So it also does not suffer the bug of line 71, I guess?

There is a deeper test that I don't know how to write that proves these "type parallelisms" are preserved. I believe that test is full typing!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant