11–20 of 45 posts
This file is insane: https://github.com/zzanehip/The-OldOS-Project/blob/master/Ol... I hate to say it but SwiftUI is tricky to write for very complex user interface...the one in that file is a nightmare imo.
This file is insane: https://github.com/zzanehip/The-OldOS-Project/blob/master/Ol... I hate to say it but SwiftUI is tricky to write for very complex user interface...the one in that file is a nightmare imo.
Reminds me of the PHP4-5 days where we'd have complex logic right within HTML components.
This is great! While I really do like the flat UI design trend, I sure do miss skeuomorphism in UI design. I underestimated the nostalgia that seeing this original design would stir up in me.
This file is insane: https://github.com/zzanehip/The-OldOS-Project/blob/master/Ol... I hate to say it but SwiftUI is tricky to write for very complex user interface...the one in that file is a nightmare imo.
This file is insane: https://github.com/zzanehip/The-OldOS-Project/blob/master/Ol... I hate to say it but SwiftUI is tricky to write for very complex user interface...the one in that file is a nightmare imo.
It could also use actual comments, and perhaps breaking more things putout into subviews.
This file is insane: https://github.com/zzanehip/The-OldOS-Project/blob/master/Ol... I hate to say it but SwiftUI is tricky to write for very complex user interface...the one in that file is a nightmare imo.
For those who have used both Flutter and SwiftUI, did you ever find that deep nesting to be very ugly and strange?
This file is insane: https://github.com/zzanehip/The-OldOS-Project/blob/master/Ol... I hate to say it but SwiftUI is tricky to write for very complex user interface...the one in that file is a nightmare imo.
Probably could have made most of the event handlers separate methods rather than lambdas. That would have made the UI structure easier to read. I don’t know Swift or SwiftUI though.
A lot of this would be broken out into it’s own file (e.g. extensions on basic types like Arrays would go in Array+Extensions.swift). Each view would go in its own file. You would break out code into separate functions instead of inlining it inside closures in the view body.
SwiftUI (though not usually Swift in general) does have a problem with over-indentation IMO. You barely have to go more than 3 levels deep in the view hierarchy you are producing before your code feels like more white space than code.
This file is insane: https://github.com/zzanehip/The-OldOS-Project/blob/master/Ol... I hate to say it but SwiftUI is tricky to write for very complex user interface...the one in that file is a nightmare imo.
Generally it’s better to compose views, by that I mean you often have to because of the compiler. I’m surprised this file even compiles! The Swift compiler usually chokes on much smaller views.
This file is insane: https://github.com/zzanehip/The-OldOS-Project/blob/master/Ol... I hate to say it but SwiftUI is tricky to write for very complex user interface...the one in that file is a nightmare imo.
I have zero experience with SwiftUI but dang, that looks really hard to read. Reminds me of the PHP4-5 days where we'd have complex logic right within HTML components.
You don't have to (and almost certainly shouldn't) write it like that.
Of course, this is just a project for fun so if this person can figure it out, more power to them. It's a neat project.
This file is insane: https://github.com/zzanehip/The-OldOS-Project/blob/master/Ol... I hate to say it but SwiftUI is tricky to write for very complex user interface...the one in that file is a nightmare imo.
Very cool project but definitely not best practice. You could reduce the number of State variables using one or more shared state objects and access via environment at certain points in the view hierarchy. Generally it’s better to compose views, by that I mean you often have to because of the compiler. I’m surprised this file even compiles! The Swift compiler usually chokes on much smaller views.
Just a personal opinion here, but those shared state objects and SwiftUI + glorified singletons really hurts every time I see it. It's so prevalent in online tutorials like Ray Wenderlich and the such.
Honestly, it's hard to avoid and can be done but requires a significant effort. I was hoping for Apple to come up with a more elegant solution during WWDC 21 but so far I haven't seen anything to improve this situation.