Comments (3)
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 ElementLayoutable
protocol has a mutable({ get set }
) LayoutProperties propertyElementType
protocol extends Layoutable and has all the methods required to do the renderingParentElementType
protocol for Element's that has children.Element
: a plain implementation ofElementType
Component<State>
: only difference is that it now conform's toElementType
instead of extendingElement
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 propertySelf
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.
from few.swift.
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.
from few.swift.
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
.
from few.swift.
Related Issues (20)
- why both in the main thread HOT 3
- Is this dead? HOT 2
- Upgrade Swift version?
- .gitignore
- Render from the topmost dirty component downward HOT 1
- [RFC] Use ComponentSpec as api for defining components HOT 5
- Nesting and flexbox HOT 5
- Multi-line labels HOT 1
- Publicly get a layout Node for an element?
- Fix iOS TableView HOT 1
- How to have overlapping elements? HOT 5
- Installation documentation? HOT 3
- Use flexbox terminology HOT 1
- Input does not seem to follow "stretch" rule HOT 5
- Add instructions in README on how to edit demo HOT 4
- Add `didRealize` hook to Component HOT 1
- iOS: table view selection doesn't really work HOT 5
- AsyncDisplayKit HOT 2
- Carthage install issue on Xcode 7.1? HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from few.swift.