-
-
Notifications
You must be signed in to change notification settings - Fork 103
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
Catching double child assignment #108
Comments
If you're defining an instance's ancestry twice, it can lead to some interesting issues, and I can't think of any good use cases for doing that anyways. Additionally, if you're re-using some part of your UI you typically should be using components. If anything, erroring on the second example forces people to think about how they're setting up their UI. For that reason I think this would be a good addition. |
Waiting for #206 to see how we should implement this. |
Unblocking this. We won't need double parent assignment - that should be impossible now - but it's still possible to attempt to parent one child into two places. I'm not sure how urgent this is though, so I'm probably not going to tackle it until down the road. |
Currently in Fusion, the following code will not error, and place both instances in
folder1
. This is because[Children]
doesn't override a manualParent
definition:The following code also doesn't throw an error, but the parent of
instance1
is undefined and prone to switching dependent on the internal implementation of Fusion:I think that in any case where an instance's ancestry is defined twice, we should throw an error, including cases where we currently allow it by giving
Parent
priority. This is a breaking change but it's likely a really bad idea to introduce this kind of ambiguity into a codebase anyway when everything is meant to be declarative, final and guaranteed to hold at all times.The text was updated successfully, but these errors were encountered: