3 ms·

>We'll also take this opportunity to automatically set translatesAutoresizingMaskIntoConstraints to false, which further makes our API easier to use Warning: y

>We'll also take this opportunity to automatically set translatesAutoresizingMaskIntoConstraints to false, which further makes our API easier to use Warning: you MUST NOT do this for UITableViewCell/UICollectionViewCells’ contentViews. https://github.com/SnapKit/Masonry/issues/492 https://github.com/SnapKit/Masonry/issues/492

saagarjha 8y ago
In general, you should not touch the layout of Apple's view classes other than using them as a reference for positioning your own views.
- aaaaaaaaaab 8y ago
  Exactly. But when people use these libraries that “helpfully” set `translatesAutoresizingMaskIntoConstraints = false` for them and they don’t understand what’s going on under the hood, their layout breaks and they start complaining about autolayout being “buggy”.
  - eugeniub 8y ago
    What's the solution in such a scenario? If I'm making custom cells, I'm going to constrain my views to the contentView. If I use a library like SnapKit, then the library sets translatesAutoresizingMaskIntoConstraints to false. Should I override that somehow and set it back to true? Should I use normal NSLayoutConstraints for all constraints involving contentView? That doesn't seem ideal.
    - aaaaaaaaaab 8y ago
      You can use the regular NSLayoutConstraints.activate() API, or you can set it back to true. Also, notice that translatesAutoresizingMaskIntoConstraints will only be set on the view which you call `layout` on. I.e. this is bogus: self.contentView.layout { make in make.left.equal(self.otherView) } But this is “fine”: self.otherView.layout { make in make.left.equal(self.contentView) } Of course now you’re relying on implementation details of SnapKot/Masonry/whatever. I personally just use the built-in anchor APIs with a few helpers (e.g. to create constraints to match all 4 edges of two views). In swift you have operator+ for arrays, so NSLayoutConstraints.activate(...) can be pretty succint this way.

saagarjha 8y ago

In general, you should not touch the layout of Apple's view classes other than using them as a reference for positioning your own views.

aaaaaaaaaab 8y ago
Exactly. But when people use these libraries that “helpfully” set `translatesAutoresizingMaskIntoConstraints = false` for them and they don’t understand what’s going on under the hood, their layout breaks and they start complaining about autolayout being “buggy”.
- eugeniub 8y ago
  What's the solution in such a scenario? If I'm making custom cells, I'm going to constrain my views to the contentView. If I use a library like SnapKit, then the library sets translatesAutoresizingMaskIntoConstraints to false. Should I override that somehow and set it back to true? Should I use normal NSLayoutConstraints for all constraints involving contentView? That doesn't seem ideal.
  - aaaaaaaaaab 8y ago
    You can use the regular NSLayoutConstraints.activate() API, or you can set it back to true. Also, notice that translatesAutoresizingMaskIntoConstraints will only be set on the view which you call `layout` on. I.e. this is bogus: self.contentView.layout { make in make.left.equal(self.otherView) } But this is “fine”: self.otherView.layout { make in make.left.equal(self.contentView) } Of course now you’re relying on implementation details of SnapKot/Masonry/whatever. I personally just use the built-in anchor APIs with a few helpers (e.g. to create constraints to match all 4 edges of two views). In swift you have operator+ for arrays, so NSLayoutConstraints.activate(...) can be pretty succint this way.