raphlinus / crochet

Explorations in reactive UI patterns
Apache License 2.0
367 stars 21 forks source link

Suggestion: shorthand for common components #4

Open Diggsey opened 4 years ago

Diggsey commented 4 years ago

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 commented 4 years ago

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.