Skip to content
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

Suggestion: shorthand for common components #4

Open
Diggsey opened this issue Sep 26, 2020 · 1 comment
Open

Suggestion: shorthand for common components #4

Diggsey opened this issue Sep 26, 2020 · 1 comment

Comments

@Diggsey
Copy link

Diggsey commented Sep 26, 2020

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.

@raphlinus
Copy link
Owner

raphlinus commented Sep 26, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants