Skip to content

๐Ÿ“ Lightweight iOS framework simplifying NSLayoutConstraint creation

License

Notifications You must be signed in to change notification settings

daehn/Constrainer

Folders and files

NameName
Last commit message
Last commit date

Latest commit

ย 

History

11 Commits
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 
ย 

Repository files navigation

Constrainer

Build Status codecov Swift 4.2 Carthage compatible

Constrainer is meant to be a lightweight AutoLayout helper. Constrainer exposes several properties on UIView that can be used to construct layout constraints using operators. This mostly was an experiment to see how much of Cartography's functionality can be replicated without using proxies only accessible in closures and the syntax of Constrainer is this heavily inspired by Cartography.

view.leading == imageView.trailing - 20
label.edges <= labelContainerView.margins.edges
let widthConstraint = view.width >= imageView.height / 2 ~ .defaultLow

All expressions return a NSLayoutConstraint (or an array of NSLayoutConstraint when using edges or center), which can be stored and used to modify / deactivate the constraint at a later point.

All available properties to construct constraints using Constrainer are:

  • top
  • bottom
  • leading
  • trailing
  • width
  • height
  • left
  • right
  • centerY
  • centerX
  • firstBaseline
  • lastBaseline
  • edges
  • center

If the constraints should be relative to margins or safe areas all of the above properties are also available on the UIView.margins and UIView.safeArea properties.

A UILayoutPriority can be set for the constraint using the ~ operator.

view.leading == imageView.trailing ~ .defaultHight
label.edges >= labelContainerView.edges ~ 750

Edges can be inset using CGFloat values or UIEdgeInset values.

label.edges >= labelContainerView.edges + UIEdgeInsets(top: 12, left: 16, bottom: -8, right: -42)
labelContainerView.edges == view.safeArea.edges - 50

Influence

Constrainer was heavily influenced by Cartography, which has a similar API but instead of exposing properties to construct constraints on the view directly it provides proxy objects inside a closure.

One main disadvantage of exposing properties with such common names directly on the view itself is potential namespace pollution (and collision), for example visible when looking at the center proxy in Constrainer, which (depending on the exact expression) might resolve to the UIView.center of type CGPoint provided by UIKit. If this happens it can be resolved by explicitly using the UIView.anchors proxy object.

About

๐Ÿ“ Lightweight iOS framework simplifying NSLayoutConstraint creation

Resources

License

Stars

Watchers

Forks

Packages

No packages published