This is the difference between knowing how to write code and software engineering. Your code needs to be readable and maintainable. By breaking your views into reusable components, not only will your UI look and work consistently across your app, but it'll save you from duplication. When you need to make a change, make it in a single place. You can go further by moving common functionality into packages, which you can just add to your future projects. Paul, it would be great to see you take the SOLID principles and translate them into SwiftUI. Since SwiftUI uses more of a functional approach than an object oriented one, not everything will apply. However, this could be a great series.
Dear Paul, you’re absolutely amazing! Thank you very much for your priceless tutorials! But I have a question for you. How did you learn all this so very well? SwiftUI is relatively new.
Great stuff mate especially the extension one. We can use XCode's in-built functionality of extract subviews for 2nd step. The most liked part of the video was your dogs though...
Thank you Paul for taking the time to teach us Swift and SwiftUI. Great content like always 👍I end up on HackingWithSwift more than StackOverflow and HackingWithSwift is more helpful.
Dear Paul, how did you know? And as always, just in time ;-) These massive and messy structs and views are not really any better than these “MassiveVCs”… Sometimes, this whole mess is getting so complex and nasty that the compiler even starts to claim that it is taking a copy from memory… This is exactly the point when it refuses to compile within a considerable amount of time - and eventually fails. Of course, Steve would have said “You are stacking it wrong”… Time to clean up and have layout and app logic separated. Being a mid level SwiftUI programmer by now, I still have difficulties to find best practise advise… I do not expect that from Apple (anymore) - but I really appreciate your help and the insights you are giving us. Thanks a lot! ;-)
I love ppl like this. Readability and structure is so important. I'm new to SwiftUI, I find it hard to change my way of thinking from C to Viewmodels. It looks a lot like C# to me, something I also found complicated when your mind thinks C. In your example, if you move code to seperate views (either in the same file or another file), is that part of the code considered a View or a ViewModel? PS love your dogs. :-)
Cool stuff. I would just add that if you're going to simplify your code to the point where something significant is just one line then that line should tell the story, which requires good naming practices. For example, at 17:00 you have collapsed the entire list generation into one line of code. But that line is much to generic to have any meaning. ForEach(items, content: ListView.init) That could literally be anything. By definition it is a list of views comprised of items. It took be a minute to even figure out what this was and I was watching you do it. I would do something like: ForEach(locations, content: LocationView.init) Otherwise, you've eliminated the signal, as well as the noise. The important thing is that you can see the layout and you're just a right-click away from jumping into the details when necessary.
It’s so weird to me that #4 is just an extension and not a custom view modifier. I’ve encountered a lot of pain with custom view modifiers and extensions always seem to work out a little better
I know this is an old post, but I find myself not understanding the rational for using a var vs a func when extracting parts of a view. Can someone explain the difference in more detail, or point me to a resource? I had started using a var unless I needed to pass arguments, in which case I would use a func. Unless it was a component that is shared by multiple parent views, in which case I make it a struct in its own file. But then I started just making things funcs rather than vars so if I needed to add an argument the capability was already there. But Paul seems to be saying there is a performance reason to prefer vars. Just looking for clarification.
Is there a reason to create a text extension rather than create something that returns a customized view? For illustration purposes it's great, but for "real" code is that how you would go it?
I like how you split up logic and views and try and not have them put together. However, I’m not the biggest fan of testing implementation details like the toggle button closure you abstracted into it’s own function. I’ve learned to only test behavior of UI and not the implementation of it. It keeps us from having to rewrite tests in the future if we decide to change the implementation. We shouldn’t have to rewrite tests for something that doesn’t change the end functionality. Thought it would be nice to share a different perspective. Great work so far!
@Paul Hudson, can you dive into the hate for @ViewBuilder a bit more? From my understanding the @ViewBuilder simply states, "If I can get a view, the use it, otherwise do nothing." And in effect gives us better control over encapsulating our logic with when and what views to present.
I think SwiftUI should/would take a few tips from React Native. They're both pretty similar in terms of paradigm/architecture (building reactive software), and many others. "Separation of concerns" where you split views into logic/UI views as much as possibile is a typical RN approach to developing apps. With that being said I definitely see some of the more traditional UIKit techniques staying around on the SwiftUI best practices list.
Lovely steps, splendid! For more stuff relating to step 2 here is my favorite on this topic: ruclips.net/video/1BHHybRnHFE/видео.html For the steps 3 through 5 I found places to improve, thank you!
I like most of your tutorials but I disagree with this one (5 Steps to Better SwiftUI Views). Should your code be taken over by another programmer, or maybe you need to make updates months later after not having seen your code in ages, applying these methods puts far away the code where the action takes place. Which makes debugging that much harder. If you want to modify a list, you have to dissect where the list is getting its data from, what it's doing with the data, how it's showing the data in list form. In other words, you have to be like a detective to figure out how the list is working because the list elements have been scattered hither and thither, it just slows you down and makes things harder. Or when you're looking to change something that a button does, now you have to jump to a couple of different code pages or multiple parts of your code from where the button is. I agree you can encapsulate view clips and just call these, but it should be that simple. Splitting up the parts further just overcomplicates things. Also, some programmers may make the mistake of applying these "optimization" tricks at the start of coding. A big no-no. If the code isn't working yet, you should first figure out the correct logic before optimizing. In the words of Dykstra: "Premature optimization is the root of all evil."
I’m just started learning. I’m not 100% sure I understand everything, but your energy is really positive and I appreciate that.
I can't upvote this enough!
So much value in a single video! Amazing job!
The best Swift "how-to". It's gorgeous!
I always learn the best programming tips and practices with your videos, they are gold.
Glad you like them!
What I learned from Paul is the process of doing things when using SwiftUI. @Paul you are one of the masters of teaching Code. #kudos
Thanks for putting this together! You deliver some great videos over the entire scope of micro to macro to best practices and we really appreciate it!
You’re amazing. I just want to give you a hug! Thanks Paul, I’m on day #8 of my coding journey and #3 on my 100 days of swiftUI THANK YOU
This is the difference between knowing how to write code and software engineering. Your code needs to be readable and maintainable. By breaking your views into reusable components, not only will your UI look and work consistently across your app, but it'll save you from duplication. When you need to make a change, make it in a single place.
You can go further by moving common functionality into packages, which you can just add to your future projects.
Paul, it would be great to see you take the SOLID principles and translate them into SwiftUI. Since SwiftUI uses more of a functional approach than an object oriented one, not everything will apply. However, this could be a great series.
Greatest tips are always embedded in your tutorials! Thank you very much for sharing.
Dear Paul, you’re absolutely amazing! Thank you very much for your priceless tutorials! But I have a question for you. How did you learn all this so very well? SwiftUI is relatively new.
Appreciate it Paul, thanks for all you do!
Great stuff mate especially the extension one. We can use XCode's in-built functionality of extract subviews for 2nd step. The most liked part of the video was your dogs though...
omg thank you for this. I've been looking for good ways to break up toolbars.
Great video. Thanks for making references to UIKit, made it much easier to understand.
Thank you Paul for great content you teach.
Awesome tips - thank you Paul. Great work
You're the best!! Always bringing some great tips and knowledge to developers of all skill levels!!
Thanks Paul I learned a lot through 100DaysOfSwift 😊
Awesome content, cannot remember the last time I watched 30min straight through on RUclips but learned a lot, thanks.
Super useful Paul - will certainly help me clean up some of my enormous views. Thanks
Breaking apart one big complex chunk of code to smaller manageable pieces is a good advice for any kind of coding, not just SwiftUI.
Wow 😍best practice for better clean code, Thank you 😊
Thanks for this awesome video. I do apply most of them regularly but after watching this video i am sure that i’m not doing anything wrong.
Thank you Paul for taking the time to teach us Swift and SwiftUI. Great content like always 👍I end up on HackingWithSwift more than StackOverflow and HackingWithSwift is more helpful.
This was so useful for a beginner like me. Thank you
Unbelieveable superb quality videos. Awesome!
Great one! This topic is huge. Well done. Thanks!
Excellent! I understood most of what you were talking about, even though that's still a bit beyond me, but I grokked.
Thank you Paul, exactly what should know each developer in SwiftUi
Love it...
Was using couple of them already... Will try to use them all from now on.👍
Tips 3,4,5 life savers !
Dear Paul, how did you know? And as always, just in time ;-)
These massive and messy structs and views are not really any better than these “MassiveVCs”…
Sometimes, this whole mess is getting so complex and nasty that the compiler even starts to claim that it is taking a copy from memory…
This is exactly the point when it refuses to compile within a considerable amount of time - and eventually fails.
Of course, Steve would have said “You are stacking it wrong”…
Time to clean up and have layout and app logic separated.
Being a mid level SwiftUI programmer by now, I still have difficulties to find best practise advise…
I do not expect that from Apple (anymore) - but I really appreciate your help and the insights you are giving us.
Thanks a lot! ;-)
This is very helpful. Thanks so much Paul 😊
Very helpful video! And lovely dogs. 🐶🐶❤️
Your videos are awesome like your dogs!
Thank you very much!
as usual @twostraws great content!
I love ppl like this. Readability and structure is so important. I'm new to SwiftUI, I find it hard to change my way of thinking from C to Viewmodels. It looks a lot like C# to me, something I also found complicated when your mind thinks C. In your example, if you move code to seperate views (either in the same file or another file), is that part of the code considered a View or a ViewModel? PS love your dogs. :-)
This will be my new bible. Subscribed 🤗
Cool stuff. I would just add that if you're going to simplify your code to the point where something significant is just one line then that line should tell the story, which requires good naming practices. For example, at 17:00 you have collapsed the entire list generation into one line of code. But that line is much to generic to have any meaning.
ForEach(items, content: ListView.init)
That could literally be anything. By definition it is a list of views comprised of items. It took be a minute to even figure out what this was and I was watching you do it. I would do something like:
ForEach(locations, content: LocationView.init)
Otherwise, you've eliminated the signal, as well as the noise. The important thing is that you can see the layout and you're just a right-click away from jumping into the details when necessary.
Great work, as always!!
hi Paul, I loved that application setup you used as a demo, could you please make a separate video to show how to build that app! please
It’s so weird to me that #4 is just an extension and not a custom view modifier. I’ve encountered a lot of pain with custom view modifiers and extensions always seem to work out a little better
🔥 awesome video!! Thank you 🙏
Great Video! Thanks as always!
Amazing Tutorial 👍
Awesome video!
Yes, we enjoyed the video 🙂
Well, this was simply excellent.
Great Content. Thanks a lot for all your efforts and content. Great contribution to iOS developer community.
I know this is an old post, but I find myself not understanding the rational for using a var vs a func when extracting parts of a view. Can someone explain the difference in more detail, or point me to a resource? I had started using a var unless I needed to pass arguments, in which case I would use a func. Unless it was a component that is shared by multiple parent views, in which case I make it a struct in its own file. But then I started just making things funcs rather than vars so if I needed to add an argument the capability was already there. But Paul seems to be saying there is a performance reason to prefer vars. Just looking for clarification.
Great tips. Thanks.
Great tips! Thanks for this. 👍
Does making these things help solving performance issues of views?
This guy is crazy in a good way 😂 25:25
SwiftUI has this component approach similar with React, that make all more appealing to me.
Thank you so much! This is great!
Great Content!
I love you Paul!
This is great. Thank you.
Thank you! Is there a way to offload all these bits to separate files and "include" them into the main routine?
Cute dog and excellent course
Wow, great stuff, Paul. Thanks a lot!
Is there a reason to create a text extension rather than create something that returns a customized view? For illustration purposes it's great, but for "real" code is that how you would go it?
I like how you split up logic and views and try and not have them put together. However, I’m not the biggest fan of testing implementation details like the toggle button closure you abstracted into it’s own function. I’ve learned to only test behavior of UI and not the implementation of it. It keeps us from having to rewrite tests in the future if we decide to change the implementation. We shouldn’t have to rewrite tests for something that doesn’t change the end functionality. Thought it would be nice to share a different perspective. Great work so far!
@Paul Hudson, can you dive into the hate for @ViewBuilder a bit more? From my understanding the @ViewBuilder simply states, "If I can get a view, the use it, otherwise do nothing." And in effect gives us better control over encapsulating our logic with when and what views to present.
I really like it! Although the style extension part sounds like working on CSS files :) But anyway I like it
Great Job Sir !
26:00 How would I make different Views for iPad and iPhone? Is `UIDevice.current.userInterfaceIdiom` still the way to go?
Thanks for video, Help me !!!
Can convert html to Text in SwiftUI?
Can we have in Text String with two colors?
You can use "+" to concatenate two Texts, like this: 'Text("Blue") .foregroundColor(.blue) + Text("Red") .foregroundColor(.red)'
@@andrewb1173 а пример с работы с jsonapi.org/ раскодировка такой структуры есть?)
You can surround the if with a Group view
In particular I like the `struct Location { static let example = ... }` in `Location.swift` Thank you!
a master class
very good, thank you.
Thanks
5:35 🤯🤯 my brain had a goosebump saying, what??? This was possible??
Thanks for sharing.
Great! Thank you.
I have never used Swift at all, some of the reviews suggest the app takes up a considerable amount of space, is this true?
thanks for sharing!
I am amazed who the hell downvotes.
So, basically, SwitUI can be used as its own kind of « CSS-like » language, in order to factor out presentation code from app logic.
Solution num2 you still have logic inside your body
what's make differences?
The same goes for large monolithic observed objects.
Nice! Thx you !
Amazing!
Dogs though 😍
The next thing in recruiting, Alignment Test.
learning swift ui and making default framework template . yeahh i hate mvc at least somebody.haha penang( from malaysia any way)
Boom!
How does ForeEach know to send the item as the named parameter without telling it the name 😲🤯
I think SwiftUI should/would take a few tips from React Native. They're both pretty similar in terms of paradigm/architecture (building reactive software), and many others. "Separation of concerns" where you split views into logic/UI views as much as possibile is a typical RN approach to developing apps. With that being said I definitely see some of the more traditional UIKit techniques staying around on the SwiftUI best practices list.
👍👍👍
Awesome video as usual, first comment :)
牛逼!
Lovely steps, splendid! For more stuff relating to step 2 here is my favorite on this topic: ruclips.net/video/1BHHybRnHFE/видео.html For the steps 3 through 5 I found places to improve, thank you!
I like most of your tutorials but I disagree with this one (5 Steps to Better SwiftUI Views). Should your code be taken over by another programmer, or maybe you need to make updates months later after not having seen your code in ages, applying these methods puts far away the code where the action takes place. Which makes debugging that much harder. If you want to modify a list, you have to dissect where the list is getting its data from, what it's doing with the data, how it's showing the data in list form. In other words, you have to be like a detective to figure out how the list is working because the list elements have been scattered hither and thither, it just slows you down and makes things harder. Or when you're looking to change something that a button does, now you have to jump to a couple of different code pages or multiple parts of your code from where the button is. I agree you can encapsulate view clips and just call these, but it should be that simple. Splitting up the parts further just overcomplicates things. Also, some programmers may make the mistake of applying these "optimization" tricks at the start of coding. A big no-no. If the code isn't working yet, you should first figure out the correct logic before optimizing. In the words of Dykstra: "Premature optimization is the root of all evil."