[1]: https://github.com/apple/swift-evolution/blob/9992cf3c11c2d5...
Edit: Also the current version of the proposal is here: https://github.com/apple/swift-evolution/blob/master/proposa...
var body: some View {
if someStateBool {
Text("True")
} else {
Text("False")
}
1. Text("True")
2. Text("False")
1. ConditionalContent(first: Text("True"))
2. ConditionalContent(second: Text("False"))
var body : some View {
if something {
return Image("hi")
} else {
return Text("hi")
}
}
In order to give the return value a type, the if statement has to be encoded in the type system itself.
You don't have to write these types because Swift can infer them. But when you write a view, you're really also stitching together a type. This explains some of the weird-feeling limitations, like no more than 10 subviews - since every possible count needs its own separate generic function! [1]
Anyways the control flow constructs are needed so it can be encoded in the type. You need a way to say "I can be this type, or that type" at the type level - that's what _ConditionalContent encodes. Not a SwiftUI expert but that's my understanding.
1: https://developer.apple.com/documentation/swiftui/viewbuilde...
I've been writing a lot of SwiftUI code since it came out - and a common use is like that example. Imagine a settings UI where you want to only show an advanced option if a switch/checkbox is toggled.
static func buildIf(_ value: SettingsConvertible?) -> SettingsConvertible {
value ?? []
}
static func buildEither(first: SettingsConvertible) -> SettingsConvertible {
first
}
static func buildEither(second: SettingsConvertible) -> SettingsConvertible {
second
}
These just return their values -- the only one of note is that buildIf returns the empty array by default, but otherwise this is just defining an if statement to be an if statement.
It gives you however to make an if statement do something other than being an if statement, and that seems... bad.
You could for example define it as
static func buildEither(first: SettingsConvertible) -> SettingsConvertible {
[]
}
static func buildEither(second: SettingsConvertible) -> SettingsConvertible {
[]
}The builder can convert expressions into components that are then assembled into results. Some applications want to be able to represent the result as a strong generic type.
As an example of this, imagine
if let releaseName = releaseName {
Div("Release \(releaseName)")
else {
Blink("Prerelease")
}
I’ve recently forayed into SwiftUI to see what all the fuss was. I have to say, I really feel for people just now starting to learn app development. Older Cocoa and iOS developers probably remember what actual in-depth articles look like, what “deep dives” actually are, etc. Instead, what we have is a culture of very shallow and information-light “articles”, that seems to me more like SEO bot posts trolling for clicks, rather than written for developers, by developers. And it’s not like the Sundells and Hudsons, but also NSHipster, CocoaWithLove, etc., which were traditionally where high-quality and information-rich content would come from in the past. Likewise with conferences, whereas in the past they’d invite developers to “deep dive” into and interesting development or debugging session, now they’ve devolved, for the most part, into these shallow, byte-sized “Swift” nonsenses. As if the language somehow defines the identity of the developers, and apps magically become much better as virtue of the language used, rather than the system frameworks.
I’m getting old.
Up until snow leopard lots of very old APIs had been kept around so actually pulling things apart was not only an interesting thing to do but even profitable (because the knowledge gained would be useful for years.) Contrast Apple's current generation of operating systems where the API churn is comparable to lots of JS frameworks. Not to mention how unfriendly the company has been to smaller developers
But Apple's documentation nowadays, is so bad (inconsistently so, some parts are fine) that these sites are filling the gap.
Further, for most other languages, Stack Overflow fits this need mostly fine. But Swift and SwiftUI have been changed so often that the accepted answer on Stack Overflow becomes outdated within a year.
And wiser.
Youth is wasted on the young. Unfortunately for the field of software development that means endless gyrations of over engineering and technobabel.
I don't consume his content (neither his website nor his podcast) but he sure knows his Swift. His recent code is probably some of the best Swift code I've seen and I have very high standards for that.
He creates amazing DSLs / abstractions / APIs by leveraging the type system which in my opinion is exactly what Swift should be about.
I also share this opinion. This hard-on that companies have of making coding easy for everyone will be the field's downfall. Just look how people are outraged whenever algorithm's are mentioned in interviews. I lost track of how many people with "senior" positions coming to interview at my company and showing that they know absolutely nothing about anything. My explanation for this is that you have a bunch of people from other areas coming to tech simply because it's easy money. They don't care about becoming the next legendary developer or something like that, they just wanna make easy money. The result is that everything gets dumbed down as a result. I really hate this and it probably means that a lot of important knowledge will be lost when the old dogs die.
But, here, this is not the case; the author makes their living from this. With the former engineers, that’s excusable. Here, less so.
I think you hit the nail on the head with this observation:
> Instead, what we have is a culture of very shallow and information-light “articles”, that seems to me more like SEO bot posts trolling for clicks, rather than written for developers, by developers.
For a while now, content's been created as a means to improve SEO, and it's really obvious when an article was written just so it contains the right mashup of keywords and that it's padded to just the right length.
And yes, I wish Apple had proper and up-to-date information on this somewhere.
Language matters just as much as the frameworks.