scottrobbins/declarativelayout

A declarative, expressive and efficient way to lay out your views.

declarativelayout's Issues

Test how this affects layout using layout framework benchmark

https://github.com/layoutBox/LayoutFrameworkBenchmark

I expect it to be worse than Autolayout and UIStackView for their respective benchmarks since it wraps them. Curious how much worse the numbers are though.

This might be a fairly boring benchmark. The library doesn't do that much on the first layout pass, so I hope it just shows that the numbers aren't that different than the autolayout benchmark.

Maybe i should also make one where it runs the benchmark where I start with a layout and then update it to what they expect if that's not too much work.

Research how much of an improvement constraint diffing is

I know apple recommends not removing all constraints, which I agree with. So I want to make sure that the amount of time the framework takes to do diffing is less than the amount of time to do another layout pass as a sanity check

Support layout guides

UILayoutGuides are a really good way to do things like bound subcomponents to that layout guide without making a dummy view.

It should look something like

viewLayout.updateLayoutTo { (component, view) in
    component.addLayoutGuide(layoutGuide) { (component, layoutGuide, superView) in 
        ...
    }
}

This should include updates to the readme for snippets and an example should use it.

Allow specifying identifier for view

One of the annoying things right now is that if you need a container view, or a layout guide, you have to pass in an instance of a view. This forces you to create a property to hold it, give it a name, etc. For things like stackviews and layout guides you rarely want to use this property outside of the layout method, and you may be creating a lot of them (especially for arranged subviews of stackviews).

To make that a little easier, I added the ability for users to call addView (and the others) without passing in an instance of a view and it would create one. The issue with this is if you need to update the view later, the new layout that is updated will have different views instantiated for this, so diffing will cause unnecessary restructuring of the view hierarchy and layout passes.

Instead, I'd like to add the ability to call addView(identifier:) (or something like that), so you wouldn't need to create a property, you'd just need to pass a unique identifier for that view. That way when you update the layout later, the framework can find the view it already has based on that identifier and reuse it.

Consider how to avoid recalculating constraint diffs for everything when making a change

So if you have a scenario where you have a complicated view and one thing changes.

• Do we want to do the work of recalculating things for all components under that viewlayout?
• Is there a way to only reload certain components without potentially causing layout issues because of the rest of the layout not changing? (programmer errors)
• If they explicitly reload certain parts, does it defeat the purpose of the library by not making it completely declarative? Is there a way to still make this declarative?

Add default view creation to component methods

Right now, the addSubview, addStackview, etc methods require you to pass in a view.

This is required for the times when you want to later call the updateLayouTo method again to change a layout, as it will allow subviews to be diffed correctly (and efficiently).

I think, however, that there are many cases (most for me) where I don't need to call that update method a second time, and it'd be nice if calling addSubview had a default argument to just instantiate a UIView (and a UIStackView for addStackview).

That would make it a lot cleaner for those times to do things like add container views, or stack views (which don't generally have styling) when you're not updating the layout again.

viewLayout.updateLayoutTo { (component, view) in 
    component.addStackView { (component, view, superview) in 
        ...
    }
}

Would definitely need to be explicit in the docs that you shouldn't do this if you need to update the layout again later or it can result in performance loss.

README should specify all constraints passed to activate should be unactivated

The framework expects all constraints passed to "activate" to be unactivated. The README should point this out, as many autolayout DSLs by default will activate constraints.

Should not have constraint issues when moving views out of UIStackView

In the README I said

UIStackViews aren't built in a way that makes it convenient to deal with the constraints they add to their arranged subviews. To avoid some hard-to-find bugs, avoid transitioning views from being arranged subviews of a UIStackView to not being arranged subviews of the UIStackView.

I kind of lied, I can build this myself. For some reason I totally missed the removeArrangedSubview method. Anyway I should support this.

Add unit tests

Yeah I don't have any unit tests, but as this api solidifies i should probably add them

Add documentation about layout component returns

Recently i added the option to get layout components returned when calling something like addSubview( instead of passing in a closure that received the component. This is to give an option that may be easier in certain circumstances for frameworks built on top of DeclarativeLayout.

This currently isn't documented in the README

Consider how to get rid of all of the `component.`

I think a real focus should be put on being able to remove the components passed into closures do you don't have to constantly call component. if possible. Perhaps abstracting the view layout out of the view controller into some class that you can subclass may be helpful. perhaps take inspiration from Elm to make this more functional (maybe break apart components a little further).

I also think this wrapper should think much harder about how to handle data to make updating state and having that trigger updates to the view easy.

Depending on how big this ends up being, it could be a separate repo that depends on this one.

Musings on how to make it easier to control the flow of data for updating your UI

originally brought up in #31

I also think this wrapper should think much harder about how to handle data to make updating state and having that trigger updates to the view easy.

Awaiting WWDC

Pretty sure i'm the only one using this library, but delaying any further work for 0.9.0 until WWDC in case they introduce the rumored declarative ui framework.

Should be examples of using other autolayout DSLs

One of the goals of the library is to be fairly unopinionated about how constraints are created. To emphasize this I think there should be one or two examples that use common autolayout DSLs like SnapKit and Anchorage.

Update to Swift 5

Swift 5 is out, should update to use that, also reset baselines for benchmarks

One more round of optimizing

In 0.7.0 I did optimizations and then added new features without a lot of consideration for optimization

In 0.8.0 I should take a look again at the things I added and see if there's room for improvement, also look into compiler annotations like @inlineable and see if any of those can help.