Generated by 🚫 Danger

I'm surprised this is compiling, UICollectionViewCell doesn't have a contentView as UITableViewCell. How is it working? 🤔

I see a contentView property for UICollectionViewCell in the header file

@SD10 yes, it is

open class UICollectionViewCell : UICollectionReusableView {

    
    open var contentView: UIView { get } // add custom subviews to the cell's contentView

I assume what's on top of @tbaranes is why do we use contentView.layer instead of layer for AnimatableCollectionViewCell. Because we can treat AnimatableTableViewCell same as the other UIView subclasses.

@mmadjer Do you remember why did we implement configureCornerRadius differently for AnimatableCollectionViewCell?

@JakeLin, because for UIColletionViewCell you have to use the layer of the contentView. Is this what you're after?

@mmadjer you are right, we should use contentView for both UICollectionViewCell and UITableViewCell.

@SD10 I tried something to eliminate the code

public protocol CellFillDesignable: class {
  var backgroundColor: UIColor? { get set }
  var contentView: UIView { get }
}

extension UITableViewCell: CellFillDesignable {}
extension UICollectionViewCell: CellFillDesignable {}

public extension FillDesignable where Self: CellFillDesignable {
  public func configureFillColor() {
    if let fillColor = fillColor {
      backgroundColor = fillColor
      contentView.backgroundColor = fillColor
    } else if let predefinedColor = predefinedColor?.color {
      backgroundColor = predefinedColor
      contentView.backgroundColor = predefinedColor
    }
  }
}

But I ended up the error like /Users/jake.lin/dev/Jake/IBAnimatable/IBAnimatable/AnimatableTableViewCell.swift:35:7: Ambiguous use of 'configureFillColor()' for AnimatableTableViewCell and AnimatableCollectionViewCell because they don't know which to use, there are two configureFillColor methods for them.

@JakeLin yeah I thought about this but it's tricky. I think most solutions I came up with did more harm than good...

e.g) polluting UIKit API, a new class, changing access control.

The object graph for this project is huge... I'm trying to limit introducing new types of any kind :(

Right now my personal policy is not to introduce a new type unless it replaces two existing types. With the exception of new features of course.

@SD10 I think your solution is acceptable. let's do it like this now.

@SD10 I think we should merge this PR first, then rebase the testing/unit-testing branch from master. Then we can review the changes trunk by trunk.