
Building DSLs in Swift - ingve
https://www.swiftbysundell.com/posts/building-dsls-in-swift
======
matchbok
So helpful, but it's crazy to me that Apple provides such horrible options for
creating UI for iOS. AutoLayout is verbose confusing mess and using
storyboards is a disaster. Why can't we have simple declarative markup to
create UI? Android's xml files are a pleasure to work with.

~~~
jawngee
Storyboards aren't a disaster, I think people's grasp of storyboard best
practices is really the disaster.

For our team, storyboards are for flow and they are broken up into individual
storyboards where possible. Individual xibs are used for views and view
controllers. We don't put any UI in storyboards at all.

Autolayout is as easy or as hard as you want to make it. As with almost all
things, less is more. I think people definitely need to have an a-ha moment
with it.

I consider it a knock against you if you can't sort out interface builder or
autolayout, if I'm being honest.

~~~
ardit33
To be honest, storyboards are either a rookie tool, or usable for small to
medium apps. Most large apps don't use them at all.

And yes, autolayout is a shitshow, hence the countless utilities and
frameworks built on top of it to make it more palatable.

~~~
bunnycorn
> Most large apps don't use them at all.

Source for that?

The only reason to not use it, is because some of those Apps are built with
third party multi-platform frameworks and not UIKit (React)

> hence the countless utilities and frameworks built on top of it to make it
> more palatable

So, having layers of abstraction, now means it sucks?

No, people make layers of abstraction because the underlying layer is useful,
powerful, configurable.

People do encapsulate AutoLayout because it works, and is good, or else, they
would be doing their own code programatically.

~~~
Aqua_Geek
> The only reason to not use it, is because some of those Apps are built with
> third party multi-platform frameworks and not UIKit (React)

Anecdote: I’ve worked on a few large iOS teams at well-known companies. At all
of them, we have moved toward building UI in code and specifically banning the
use of XIBs and Storyboards (we still use all of Apple’s frameworks — e.g.
UIKit). Part of the reason is merge conflicts — in much the same way that
merging Xcode project files requires every engineer to understand and be able
to parse the syntax when looking at a diff, merging changes in XIBs and
Storyboards is fraught with danger (at best).

~~~
bunnycorn
We don't have that problem, we have CI with UI tests.

~~~
mpweiher
Wow, your CI automagically fixes merge conflicts?

------
saagarjha
I don’t quite see the need for LayoutProxy, or a layout method. Why not just
extend UIView with a category which defines properties that add constraints
when assigned to?

~~~
bunnycorn
The article is not about AutoLayout. It's about DSL's, most commenters didn't
even read the article, and jumped right to poo-pooing AutoLayout.

~~~
saagarjha
Your comment might be useful in the context of this entire comment section,
but I don't really see why you've chosen to reply to me in particular.

------
aaaaaaaaaab
>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
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
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
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
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.

------
lmcd
Something similar here:
[https://github.com/lmcd/EasyAnchors](https://github.com/lmcd/EasyAnchors)

