if he said smth doesn't mean it's the correct way :) this approach will not work in really big projects :) in small ones - sure, in big ones, oh boy. just switch on your common sense.
For iOS 17 and the new Observation framework, this pattern will make sense. Also, for iOS17, the view will not be reloaded unless the view got changed.
You can actually use an in-memory database that is created with each test run. But if you use a real database, then yeah. In this case it's better to just mock the database
This feels so wrong to me, it's like going back to the beginning but instead of having massive view controllers, we now have massive... views??? For small personal projects or tutorials (like the ones you showed from Apple), this should be enough. But in real world applications where many developers are working in one app, this pattern won't let each other to safely edit a complex view. We use automatic tests for view models AND views because many developers might be working on a single view/feature, we can't just test manually or use xcode previews... anyways
You are totally right and we should never forget that Apple's suggestions in usage of their frameworks are good only for a 3 screens todo app. And thus should be ignored in favor of SOLID principles.
what feels right to you. Please also explain? How would we use Fetch request or Environments? How Child views are going to use the shared Data? @davidlangley9287
Hi Azam, thank you for your beautiful SwiftUI Architecture and Best Practices talk. I have a question though. In the 50 minutes of Count example, you mentioned view whose state property doesn't change, it doesn't get recreated but rather reevaluated. But I tried setting random colors to Text. Every time when I press the Increament button the count increases and also color of Counter changes even though it is a static text. Can you explain that?
One important caveat to this approach, he based it on his experience creating 200 prototypes in a couple of years... That leaves you with very low complexity per each app, so what he says indeed makes sense in that context, but if you are a team of 15 devs working on a single complex app, that's a different scenario completely, and his advice for large apps are not battle tested, he just thinks it will probably work...
Nice approach, not applicable in big projects also remind me the masive view controller and seems too permisive to where business logic resides, not so good for clarity on big projects, tutorial projects will be fine.
On the contrary, I have completed several very large projects using this approach and it worked out very well. We were able to reduce at least 40% of the code by not creating VM for every single screen. Less code is always better.
@azamsharp how exactly it reduces 40% the code, the business logic is just moved somewhere else, if is not in the VM it in a Reducer or Presenter or Model or in the View(which is the worst), and in most cases when the business logic is not where expected it reduces code clarity. I have my concerns that this can be applied in large projects and improve the project.
We can create whole app in single file but that does not mean we should, same way we can write whole logic in view class sill it will work that does not mean we should
At first I was concerned about organization, but by the end of it, I completely agree. Great talk.
Mayyybe a slight disagreement on some of the testing strategies, but that's minor
Never knew i was doing the exact way how Azam did and thought myself it was wrong until watching this video. Great talk ❤
if he said smth doesn't mean it's the correct way :) this approach will not work in really big projects :) in small ones - sure, in big ones, oh boy. just switch on your common sense.
For iOS 17 and the new Observation framework, this pattern will make sense. Also, for iOS17, the view will not be reloaded unless the view got changed.
48:00 We can't run tests in parallel in this case, right?
You can actually use an in-memory database that is created with each test run. But if you use a real database, then yeah. In this case it's better to just mock the database
Great talk! This is so similar to modern react, which is great!
This feels so wrong to me, it's like going back to the beginning but instead of having massive view controllers, we now have massive... views???
For small personal projects or tutorials (like the ones you showed from Apple), this should be enough. But in real world applications where many developers are working in one app, this pattern won't let each other to safely edit a complex view. We use automatic tests for view models AND views because many developers might be working on a single view/feature, we can't just test manually or use xcode previews... anyways
If you views are getting bigger then divide them into smaller views.
You are totally right and we should never forget that Apple's suggestions in usage of their frameworks are good only for a 3 screens todo app. And thus should be ignored in favor of SOLID principles.
Answer for Bigger apps at 28:00
what feels right to you. Please also explain?
How would we use Fetch request or Environments?
How Child views are going to use the shared Data?
@davidlangley9287
I like the thinking behind your presentation - have to consider it in the future. What are you using to align the closing braces visually?
Hi Azam, thank you for your beautiful SwiftUI Architecture and Best Practices talk. I have a question though. In the 50 minutes of Count example, you mentioned view whose state property doesn't change, it doesn't get recreated but rather reevaluated. But I tried setting random colors to Text. Every time when I press the Increament button the count increases and also color of Counter changes even though it is a static text. Can you explain that?
Code example?
@@azamsharp
struct ContentView: View {
@State var count = 0
var body: some View {
let _ = Self._printChanges()
VStack {
Image(systemName: "globe")
.imageScale(.large)
.foregroundStyle(.random)
Text("Counter")
.font(.largeTitle)
.foregroundStyle(.random)
Text("\(count)")
Button("Increment") { count += 1 }
.frame(width: 124, height: 32)
.tint(.random)
.background(.random)
}
}
}
extension ShapeStyle where Self == Color {
static var random: Color {
Color(
red: .random(in: 0 ... 1),
green: .random(in: 0 ... 1),
blue: .random(in: 0 ... 1)
)
}
}
But if I refactor the code to following, it works fine:
struct ContentView: View {
@State var count = 0
var body: some View {
let _ = Self._printChanges()
VStack {
AnotherView()
.background(.random)
Text("\(count)")
Button("Increment") { count += 1 }
.frame(width: 124, height: 32)
.tint(.random)
.background(.random)
}
}
}
struct AnotherView: View {
var body: some View {
Image(systemName: "globe")
.imageScale(.large)
.foregroundStyle(.random)
Text("Counter")
.font(.largeTitle)
.foregroundStyle(.random)
}
}
extension ShapeStyle where Self == Color {
static var random: Color {
Color(
red: .random(in: 0 ... 1),
green: .random(in: 0 ... 1),
blue: .random(in: 0 ... 1)
)
}
}
@@mohammedrokonuddin7153 The .random gets called during evaluation and the view gets redrawn.
"I am going to test this manually" lost me :D
I personally invest my time on writing tests for the domain logic.
Exactly!! lol "I am going to test this manually"
One important caveat to this approach, he based it on his experience creating 200 prototypes in a couple of years... That leaves you with very low complexity per each app, so what he says indeed makes sense in that context, but if you are a team of 15 devs working on a single complex app, that's a different scenario completely, and his advice for large apps are not battle tested, he just thinks it will probably work...
great video
thank you
Can you please talk about The Composable Architecture.
Nice approach, not applicable in big projects also remind me the masive view controller and seems too permisive to where business logic resides, not so good for clarity on big projects, tutorial projects will be fine.
On the contrary, I have completed several very large projects using this approach and it worked out very well. We were able to reduce at least 40% of the code by not creating VM for every single screen. Less code is always better.
@azamsharp how exactly it reduces 40% the code, the business logic is just moved somewhere else, if is not in the VM it in a Reducer or Presenter or Model or in the View(which is the worst), and in most cases when the business logic is not where expected it reduces code clarity. I have my concerns that this can be applied in large projects and improve the project.
Also why “less code is always better” this is so wrong
We can create whole app in single file but that does not mean we should, same way we can write whole logic in view class sill it will work that does not mean we should
Test manually lol :). This is not a good practice