duethealth / gooey Goto Github PK

Right now, BoundingAnchor provides convenience methods for constraining a view "to a view controller." Internally, this is using the target controller's layout guides and/or view based on iOS version. This definition should be deprecated and replaced with a more-generic one which accepts any UILayoutGuide. To support the deprecated behavior in full, a convenience property of UIViewController which returns a UILayoutGuide corresponding to the version-agnostic safe area of the view could be used instead.

It is fairly typical to need to reduce priority for constraints within reusable views to prevent console logs about breaking constraints to acquiesce to UIView-Encapsulated-Layout-Width.

It would be nice if ConstraintGroups supported doing this simply:

NSLayoutConstraint.goo.activate([
    someView.goo.boundingAnchor.makeHorizontalEdges(equalTo: self, insets: .both(.system)).with(priority: .defaultHigh)
])

In this function it is insetting the passed in parameter by its self instead of insetting the property insets that exists on the instance.

Additionally the inset is occurring in the wrong direction for bottom and right constraints:

From Apple's documentation:

Positive values cause the frame to be inset (or shrunk) by the specified amount. Negative values cause the frame to be outset (or expanded) by the specified amount.

To honor that we must negate the bottom and right for the values of the constants.

Right now, the internals of ColorToken only store the [0...255] RGB components. This is fine for a naive implementation and most use cases. For any more robust usages involving other representations, though, the current backing mechanism causes a loss of information. Take, for example, the changes staged in #45. The color white (rgb(255, 255, 255)) is infinite:

ColorToken(hue: .random(in: 0...1), saturation: 0, value: 1)

but for those more robust usages, the following is not necessarily true:

// Does not always hold.
ColorToken(hue: .random(in: 0...1), saturation: 0, value: 1) == ColorToken(hue: .random(in: 0...1), saturation: 0, value: 1)

The proposed solution is to introduce a private nested type for retaining the raw values used to initialize the ColorToken instead of always calculating the RGB components. The existing property accessors/mutators would need modified to either calculate or just return depending on what the storage has retained.

A (perhaps) less-than-desirable consequence of pursuing this change is that equality of two colors becomes a little more complicated. Merely conforming to Equatable is not an option, but it is easy enough to introduce color comparers which know how to reconcile the various properties.