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
For example, button("text", cx) could be shorthand for Button::new("text").build(cx), and this could be a standard pattern for simple components.
The question is: would the simple form be usable in enough places to make it worthwhile? I hope that styling/layout information could be managed out-of-band - perhaps loaded from a file and then mapped onto the widget tree using the stable widget identities, so that you would rarely need to stray from this short form.
Some components might have multiple variations, eg. image_button(..., cx) but if there are more than a couple of common forms it would be better to revert back to the factory style for that component.
The text was updated successfully, but these errors were encountered:
There's a thread on the Zulip where we were wrestling with this very question. It's a case where I think real keyword arguments would come in handy.
The reason to use this builder pattern is consistency with the case where you are supplying (in many cases optional) attributes. Another alternative that was discussed is a params struct with { .. Default::default() } to represent optionality. Unfortunately, that also is an unwelcome amount of noise.
Styling is another complex question, and one I'd like to tackle at some point after feeling more confident about the basic reactive architecture. CSS is the devil we know: powerful, and very widely used, but I'm not sure very many people would argue it's the right way to do this. But yes, if there is an out-of-band channel for styling, it might take off some of the pressure to supply attributes when building the view tree.
For example,
button("text", cx)
could be shorthand forButton::new("text").build(cx)
, and this could be a standard pattern for simple components.The question is: would the simple form be usable in enough places to make it worthwhile? I hope that styling/layout information could be managed out-of-band - perhaps loaded from a file and then mapped onto the widget tree using the stable widget identities, so that you would rarely need to stray from this short form.
Some components might have multiple variations, eg.
image_button(..., cx)
but if there are more than a couple of common forms it would be better to revert back to the factory style for that component.The text was updated successfully, but these errors were encountered: