Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Varadic range support #140

Merged
merged 6 commits into from
Jul 6, 2017
Merged

Varadic range support #140

merged 6 commits into from
Jul 6, 2017

Conversation

vlozko
Copy link
Contributor

@vlozko vlozko commented Jun 29, 2017

Allows the BrickKit collection view controller to apply different dimensions based upon how wide the brick is. Starting with a minimum dimension that would be applicable to all widths, the app can the specify different dimensions for any additional widths.

100% code coverage for all additional code.
Added code to sample app to demonstrate support for it.

Copy link
Contributor

@thevwu thevwu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes to how we call the new dimensionRange

@@ -18,39 +18,106 @@ public struct BrickSize {
}
}

public typealias RangeDimensionPair = (dimension: BrickDimension, minimumLength: CGFloat)

public struct BrickRangeDimention {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should be Dimension

indirect case auto(estimate: BrickDimension)
indirect case orientation(landscape: BrickDimension, portrait: BrickDimension)
indirect case horizontalSizeClass(regular: BrickDimension, compact: BrickDimension)
indirect case verticalSizeClass(regular: BrickDimension, compact: BrickDimension)

indirect case dimensionRange(range: BrickRangeDimention)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ideally this would be

indirect case dimensionRange(minimum: BrickDimension, additionalRangePairs: [RangeDimensionPair]?)

case .verticalSizeClass(let regular, let compact):
let isRegular = BrickDimension.verticalInterfaceSizeClass == .regular
return (isRegular ? regular : compact).dimension
return (isRegular ? regular : compact).dimension(withValue: value)
case .dimensionRange(let dimensionRange):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the change to the indirect case, you now initialize the BrickRangeDimension here instead

let additionalRangePairs1: [RangeDimensionPair] = [(dimension: .ratio(ratio: 1/2), minimumLength: CGFloat(350))]
let dimensionRange1: BrickDimension = .dimensionRange(range: BrickRangeDimention(minimum: .ratio(ratio: 1.0), additionalRangePairs: additionalRangePairs1))
let additionalRangePairs2: [RangeDimensionPair] = [(dimension: .ratio(ratio: 0.5), minimumLength: CGFloat(350))]
let dimensionRange2: BrickDimension = .dimensionRange(range: BrickRangeDimention(minimum: .ratio(ratio: 0.5 + 0.5), additionalRangePairs: additionalRangePairs2))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a fan of calling enum .dimensionRange and then initializing an object that is BrickRangeDimension, provided comments on how to adjust this call so that it's similar to the other BrickDimension cases we have

@codecov-io
Copy link

codecov-io commented Jun 29, 2017

Codecov Report

Merging #140 into master will increase coverage by 0.1%.
The diff coverage is 98.3%.

Impacted file tree graph

@@            Coverage Diff            @@
##           master     #140     +/-   ##
=========================================
+ Coverage   93.25%   93.35%   +0.1%     
=========================================
  Files          38       38             
  Lines        3097     3144     +47     
=========================================
+ Hits         2888     2935     +47     
  Misses        209      209
Impacted Files Coverage Δ
Source/Cells/BrickCell.swift 97.8% <100%> (ø) ⬆️
Source/Bricks/Image/ImageBrick.swift 77.98% <100%> (ø) ⬆️
Source/Models/BrickDimension.swift 99.09% <100%> (+0.62%) ⬆️
...rs/BrickCollectionView+BrickLayoutDataSource.swift 100% <100%> (ø) ⬆️
Source/Bricks/Collection/CollectionBrick.swift 84.31% <50%> (ø) ⬆️
Source/ViewControllers/BrickCollectionView.swift 95% <0%> (+0.03%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 183af9e...8b5a000. Read the comment docs.

@@ -18,39 +18,106 @@ public struct BrickSize {
}
}

public typealias RangeDimensionPair = (dimension: BrickDimension, minimumLength: CGFloat)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is Length the correct term? Should we use minimumWidth?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was uncertain about this one for a while, too. I wanted this to be applicable for height-based dimensions, too. However, I noticed in the code that we only support direct cases for height brick dimensions. I don't know if that's by design or a shortcoming. There's no good generic term that would encompass both width and height. For example, size is already reserved for a struct that contains both width and height.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're already using size for .fixed(size: 200)? I think if we come up with the right terms, we should change it there too (might be some refactor on the WayfairApp though)...


internal var dimensionPairs : [RangeDimensionPair]

public init(minimum dimension: BrickDimension, additionalRangePairs: [RangeDimensionPair]?) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could we use default instead of minimum? Or fallBack?


internal var dimensionPairs : [RangeDimensionPair]

public init(minimum dimension: BrickDimension, additionalRangePairs: [RangeDimensionPair]?) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we make it non-optional and default it to []?

}
}

public func dimension(forWidth width: CGFloat?) -> BrickDimension {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is width optional?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It returns the default/minimum one if one isn't provided.

indirect case auto(estimate: BrickDimension)
indirect case orientation(landscape: BrickDimension, portrait: BrickDimension)
indirect case horizontalSizeClass(regular: BrickDimension, compact: BrickDimension)
indirect case verticalSizeClass(regular: BrickDimension, compact: BrickDimension)

indirect case dimensionRange(minimum: BrickDimension, additionalRangePairs: [RangeDimensionPair]?)

public var isEstimate: Bool {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we pass the width here too?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Swift doesn't allow you to provide default arguments for an enum case.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could we make it a func instead?
public func isEstimate(withValue value: CGFloat) -> Bool

case .auto(_): return true
default: return false
}
}

var dimension: BrickDimension {
func dimension(withValue value: CGFloat? = nil) -> BrickDimension {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we make it non-optional?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The concern here is that only one case actually needs to use a value. We'd be forcing people to provide a completely unused value for all the other cases.

return lhs.dimension == rhs.dimension && almostEqualRelative(first: lhs.minimumLength, second: rhs.minimumLength)
}

public func ==(lhs: BrickRangeDimension, rhs: BrickRangeDimension) -> Bool {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there no unit test for this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There were but the last commit ended up modifying the coverage. I'll add additional tests to handle the additional cases.

…l unit tests for more complete code coverage.
default: return self
}
}

func value(for otherDimension: CGFloat, startingAt origin: CGFloat) -> CGFloat {
let actualDimension = dimension
let actualDimension: BrickDimension = dimension(withValue: otherDimension)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need this type here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It did at one point. I can remove it.

@jay18001
Copy link
Contributor

jay18001 commented Jul 5, 2017

Can you add an example playground

@jay18001 jay18001 merged commit 6b48463 into wayfair-archive:master Jul 6, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants