Introducing "IB" #no-public-changes

[tbaranes]

I take a look at #528 to make IBAnimatable working without interface builder, AND without subviews.

This PR implements a working solution for this issue, currently supporting:

• FillDesignable
• CornerDesignable

Usage:

view.ib.cornerRadius = 12
view.ib.opacity = 0.1
view.ib.fillColor = .green
view.ib.predefinedColor = ColorType.flatAlizarin

In order to get this, I had to change each protocols to add a configure(in view: UIView) since ib is not a view itself. It will ask a bit of work to refactor all of them, but it will work in the end. There's one issue left: how to "reload" the properties when rotating, bounds did change... all the work currently in layoutSubviews

Other branches related to this feature ready to go (after a rebase):

• feature/ib_borderdesignable

Also, I don't know how we should document (documentation + demo project) this, any suggestions?

[JakeLin]

@tbaranes 💪 thanks for picking up this feature quickly, it is a fun and challenging one. It is a great start 👍

I had to change each protocols to add a configure(in view: UIView) since ib is not a view itself.

I think we need to do more than just UIView, some of them are not UIViews. I haven't seen any better way to achieve the goal without doing that yet

how to "reload" the properties when rotating,

Is it possible to provide a reload method like view.ib.reload to ask the user to call? It will call configureAfterLayoutSubviews() and autoRunAnimation()

I don't know how we should document (documentation + demo project) this, any suggestions?

I prefer adding code comments as documentation now. We may add documentation comment in class IB, we can refer to how the other libraies doing , for example, RxSwift. And using a playground is good for demonstrating the API in done.

[tbaranes]

I think we need to do more than just UIView, some of them are not UIViews. I haven't seen any better way to achieve the goal without doing that yet

Which component do you have in mind? Anyway, I think we can start by supporting only UIView then add the others later by keeping a list in #528

I prefer adding code comments as documentation now. We may add documentation comment in class IB, we can refer to how the other libraies doing , for example, RxSwift. And using a playground is good for demonstrating the API in done.

Sounds good to me, I don't really have a preference. Should we create a dedicated PR for this once the feature itself is more advanced?

[tbaranes]

reload() method added, I think it's ready to go beside documentation (depending if we make the documentation in this PR or in a new one)

[tbaranes]

Travis failing due to the tests, will pass once #530 has been merged and rebased

[IBAnimatableBot]

	2 Warnings
⚠️	Consider adding supporting documentation to this change. Documentation can be found in the docs directory.
⚠️	Consider adding / updating the demo ap.

Generated by 🚫 Danger

[tbaranes]

@JakeLin Ready for final review considering that docs will be added in another PR!

[JakeLin]

👍 It's good to go

[JakeLin]

@tbaranes

Which component do you have in mind? Anyway, I think we can start by supporting only UIView then add the others later by keeping a list in #528

I was thinking some components like AnimatableBarButtonItem. They are not UIViews

[JakeLin]

@tbaranes great work 👍