You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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!
The text was updated successfully, but these errors were encountered:
snabbdom-pragma/src/index.js
Line 71 in afc9651
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!
The text was updated successfully, but these errors were encountered: