{"id":36990,"date":"2022-09-09T15:29:40","date_gmt":"2022-09-09T19:29:40","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=36990"},"modified":"2022-09-10T08:40:15","modified_gmt":"2022-09-10T12:40:15","slug":"using-lazy-properties-for-views","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2022\/09\/09\/using-lazy-properties-for-views\/","title":{"rendered":"Using Lazy Properties for Views"},"content":{"rendered":"

Steve Landey<\/a>:<\/p>\n

There are three patterns I use in most of my UIKit projects that I’ve never seen anyone else talk about. I think they help readability a lot, so I’m sharing them here[…]<\/p>

[…]<\/p>

Additionally, it’s not great to use force-unwrapped optionals to store anything. But if we use let<\/code> instead, then all views will be created at init time instead of in loadView()<\/code>.<\/p>

[…]<\/p>

We can solve a lot of problems by moving all view creation to the bottom of the file and using lazy var<\/code>.<\/p><\/blockquote>\n

The standard guidance is to use implicitly unwrapped optionals to reference views in a view controller, but I think lazy<\/code> works much better. Aside from the delayed loading benefit, lazy<\/code> lets you reference self<\/code>, and thus other properties and helper methods, which you would not ordinarily be able to do from a Swift initializer. (The compiler does protect you from making circular references to other lazy<\/code> properties.) And, because you are providing an initial value, the type of the property can be inferred.<\/p>\n

A downside is that there’s no lazy let<\/code>, so the compiler can’t prevent you from accidentally mutating a variable that you meant to only set once. One way around this is to use a helper object with all the properties as let<\/code> and to store that<\/em> in the var<\/code>, but I think the awkwardness this causes is worse than the problem it solves. Landey suggests:<\/p>\n

You can at least prevent multiple writes to vars<\/code> at runtime by using this simple property wrapper, which throws an assertion failure in debug builds if you write to the property more than once. It’s not as good as a compile-time guarantee, but it does double as inline documentation.<\/p><\/blockquote>\n

You can decide whether the protection is worth the noise. I’m more interested in something like this to prevent write access to conceptually immutable properties except from tests. However, that is more relevant for model properties, which often use Core Data, and property wrappers don’t work with @NSManaged<\/code>. Core Data itself provides a—more verbose—out, though: you can still set a property with a private<\/code> setter by key.<\/p>\n

Landey then recommends defining the properties at the top of the file and using helper functions at the bottom of the file to actually create the views. Personally, I prefer to see everything related to a property together at its declaration. If you use lazy<\/code> and create the initial value right there, you can set up the whole property without having to repeat its name or type anywhere.<\/p>\n\n

Previously:<\/p>\n