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
and all the Labels and Buttons automatically become children of the StackLayout. And the StackLayout becomes a child of the Page component. Nice and clean and precise.
Everyone is used to this; Behind the scenes children are automatically assigned to the parent via the _addChildFromBuilder function.
While messing with the FormattedString I realized it (and several other components) are totally inconsistent with the above clean method of declaring the UI. So lets take the following example:
Why do I need to create the <FormattedString.spans> element. We know already that spans is the ONLY element that are children of the FormattedString. So if we added a _addChildFromBuilder to both the Label and FormattedStrings
couldn't we then totally eliminate the <Label.formattedText> and <FormattedString.spans> and make it:
Wouldn't that be much more consistent with the clean Declarative UI. Since the only valid child component of a Label is a .formattedText and the only valid children of a FormattedString are Spans? Technically, we could even detect if was being passed in as the child, and then dynamically create a FormattedString parent object. So then:
Would work. 😀 Now, who doesn't think that is WAY simpler to code and read?
Please note; we would still leave the _addArrayFromBuilder on all these components so that you could do the Long hand version (and so all existing code would continue to work). But looking at the code base I don't see any reason why we can't enhance most components that have only one child component type and/or one primary child component type.
The text was updated successfully, but these errors were encountered:
you are absolutely right about this. I was considering implementing this change but I wanted to make it more general purpose. What I mean is to decorate with some attribute which is the default property so if you omit <Label.formattedString> it will automatically find on which property this should be applied. Additionally I want the detector (probably component-builder) to detect if this is an array or simple property so there is no need to implement _addArrayFromBuilder.
I just noticed this and decided to bring this up as a discussion point. I'm willing to start doing pull requests if you all agree with my logic.
Normally in the Declarative XML you typically do:
and all the Labels and Buttons automatically become children of the StackLayout. And the StackLayout becomes a child of the Page component. Nice and clean and precise.
Everyone is used to this; Behind the scenes children are automatically assigned to the parent via the _addChildFromBuilder function.
While messing with the FormattedString I realized it (and several other components) are totally inconsistent with the above clean method of declaring the UI. So lets take the following example:
Why do I need to create the <FormattedString.spans> element. We know already that spans is the ONLY element that are children of the FormattedString. So if we added a _addChildFromBuilder to both the Label and FormattedStrings
couldn't we then totally eliminate the <Label.formattedText> and <FormattedString.spans> and make it:
Wouldn't that be much more consistent with the clean Declarative UI. Since the only valid child component of a Label is a .formattedText and the only valid children of a FormattedString are Spans? Technically, we could even detect if was being passed in as the child, and then dynamically create a FormattedString parent object. So then:
Would work. 😀 Now, who doesn't think that is WAY simpler to code and read?
Please note; we would still leave the _addArrayFromBuilder on all these components so that you could do the Long hand version (and so all existing code would continue to work). But looking at the code base I don't see any reason why we can't enhance most components that have only one child component type and/or one primary child component type.
The text was updated successfully, but these errors were encountered: