Re-think in light of protocol extensions

[joshaber]

Now that protocols can have concrete implementations, we should re-visit whether Few can be designed around value types and protocols. :sparkles:

[ghost]

This would be a huge improvement! I did a little proof of concept and here are the results:

Types

• LayoutProperties struct that has all information about how to layout the Element
• Layoutable protocol has a mutable({ get set }) LayoutProperties property
• ElementType protocol extends Layoutable and has all the methods required to do the rendering
• ParentElementType protocol for Element's that has children.
• Element: a plain implementation of ElementType
• Component<State>: only difference is that it now conform's to ElementType instead of extending Element

Extensions the idea is that most of the methods on Element can be added as extension of Layoutable or ParentElementType.

• For Layoutable
  • func width(width: CGFloat) -> Self
  • func height(height: CGFloat) -> Self
  • func direction(direction: Direction) -> Self
  • func flex(flex: CGFloat) -> Self
  • func childAlignment(alignment: ChildAlignment) -> Self
  • func selfAlignment(alignment: SelfAlignment) -> Self
  • func justification(justification: Justification) -> Self
  • func margin(edges: Edges) -> Self
  • func size(width: CGFloat, _ height: CGFloat) -> Self
• For ParentElementType
  • func children(children: [ElementType]) -> Self

Challenges

• We must avoid associated values in our protocol's. Associated values force you to use generics to infer the type of the children array and that is problematic if you want multiple different elements as your children. I don't know how we are going to tackle this, currently applyDiff has a property Self and that also requires to infer the type using generics.
• We can't use mutating functions if we use protocol extensions But there's a workaround for this:

This is just to start a discussion about how it's all going to work.

[joshaber]

This is great, thanks for starting to think through it!

I'm wondering what the motivation is for separating ElementType and Layoutable? It seems unlikely we'd need one without the other.

[ghost]

I'm wondering what the motivation is for separating ElementType and Layoutable? It seems unlikely we'd need one without the other.

Mostly because this was a proof of concept and the first thing i wanted to do was add protocol extensions for mutating the layout properties. I agree, we don't need Layoutable.