Repository navigation
Expand types for insert after/before - #802
Conversation
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 50975a3:
|
Codecov Report
@@ Coverage Diff @@
## master #802 +/- ##
=======================================
Coverage 97.52% 97.52%
=======================================
Files 126 126
Lines 7927 7927
Branches 1824 1824
=======================================
Hits 7731 7731
Misses 196 196
Continue to review full report at Codecov.
|
|
@maier49 I think this is backwards compatible and fixes the ability to insert siblings - at the moment it types children to the wrapped siblings child type which isn’t correct at all. The fix would allow the children type of the parent to be violated like you mention though. I think the correct fix for the next major release would be to require the parent on the API to be able to correctly enforce the child type when working with siblings. |
Change insertBefore/After to allow any template children rather than typing based on the targeted node.
* Fix types for insert after/before (#802) Change insertBefore/After to allow any template children rather than typing based on the targeted node. * Fix: Rendering for multiple nested `head` and `body` nodes (#812) * failing unit test for nested body and head tags * skip head or body node when finding insert before node * move JSX types to tsx namespace (#818) * fix unit test that was missed on master Co-authored-by: Bradley Maier <bmaier@sitepen.com>
2 participants
Type: bug
The following has been addressed in the PR:
prettieras per the readme code style guidelinesDescription:
This expands the types for
insertBefore/insertAfter. This would I believe be a backwards compatible fix but I think may be the appropriate fix in general.We currently allow inserting before/after at the root and when the parent is not wrapped, and requiring a parent would break both of those use cases. Making the parent argument optional could allow the user to opt into typing but seems klugey since the parent isn't actually needed.
Additionally the only concern with widening the type is that we'd allow the parent's child type to be violated, but even if we enforced it here the
replacefunction accepts any DNode. It seems inconsistent if our API enforces the types of siblings but not the node itself.Resolves #801