api refactoring propositions

[jaroslaw-weber]

I think there is still a room for little refactoring. Here are few propositions.

How about change of

WidgetBuilder::set_draw_style

to set_style?

---

I would suggest change naming of WidgetModifier also the method from_modifier. The name is confusing and I there is no documentation currently. Only have apply method, so how about Apply trait? Or WidgetApply?

Also,

WidgetBuilder::from_modifier(List::default());

you basically create a default list. Maybe "WidgetBuild::create_from(List::default())" or implement From trait for the current widget modifier? It would be possible to write:

let wb = WidgetBuilder::from(List::default());

---

There is lot of some_widget.layout().add(contstraints!...) repeating in the examples. Since contraints is a macro itself, how about putting a target widget builder inside macro?

list_widget.layout().add(constraints![shrink(), match_width(&scroll_widget)]);

change to something like (not sure if possible):

constrain!{
    target: list_widget,
    shrink(),
    match_width(&scroll_widget)
}

In this case we are hiding mutating a state so maybe not so good idea. How about:

list_widget.add(constraints![...])

or

list_widget.constrain(align_top(&container))

or

list_widget.add_rule(align_top(&container))

?

We could also consider changing "constrain" to "rule" since its shorter and easier to type.

[wendivoid]

I have one little api change I'd also like to propose, changing the 'component_style' macro to 'styled_component', the first to me one implies that it only creates the the 'Style' for a component but the second one implies it creates the component and the style, witch is more accurate i think.

[christolliday]

Thanks for this, sorry that things are moving a little slowly at the moment. There is certainly plenty of room for refactoring, remember this is an experimental library! In general making things as concise as possible isn't a high priority at the moment though, either because APIs are likely to get replaced entirely or redesigned (WidgetModifier), or be hidden in lower levels and not be exposed as directly as they are at the moment (constraints), but there is a good chance something like add_rule will get added eventually but I want to avoid it until it's necessary. As for component_style, it is a little confusing but I think styled_component implies more an instance of a component that has been styled rather than the schema of attributes that can be styled, which both Structs represent. Maybe styleable_component would be better.