Steve Troughton-Smith

I can't stand modifier-driven-development in SwiftUI; don't like how it reads, don't like how it works. They mix event handling with view properties with visual decoration, can end up nesting in horrible ways inside of various kinds of brackets, and just make for an unavoidable mess.

My question is: if Apple were to replace modifiers with something *better*, is there a viable alternative within the syntax Swift makes available today, or would the language need new features?

Sep 27, 2023 at 1:45pmIvory for Mac
Show threadSteve Troughton-SmithSep 27, 2023
Would it make sense to disconnect visual elements from functional modifiers, perhaps, in some kind of stylesheet system? Like with Xcode's new macro support, could visual modifiers be hidden away by default but revealable at a moment's notice?
Show threadMagnus JensenSep 27, 2023
@stroughtonsmith I mean - styles are used plenty in SwiftUI
Show threadJeffreySep 27, 2023

@stroughtonsmith hm, interesting thought experiment… 🤔

You can already make a View extension that combines multiple (visual) modifiers, abstracting them away in a single modifier. It’s not revealable inline, but jumping to the definition of the modifier is still a quick way to see the underlying code.

Show threadEslam NasserSep 27, 2023
@stroughtonsmith
The whole premise of SwiftUI is how “fast” you can iterate between event handling and visual declarations, and I feel like the whole framework is built around this idea, so I don’t see how Apple could introduce something else…
Show threadJosh GarnhamSep 27, 2023
@stroughtonsmith Agree. We try to format in a specific way so that visual decoration modifiers are used first before event handling. We also separate out a ‘Logic’ extension for any View related logic functions. But it still gets hard to read.
Show threadKarl BaronSep 27, 2023
@stroughtonsmith This is something I always hated about jQuery back in the day. I was always a mootools guy and never understood why people loved jQuery so much since the modifier-driven syntax never made any logical sense to me, and the generic naming of everything was even worse. Like, why are you calling functions on results? What does this MEAN? .click()?!?!
Show threadJames HarveySep 27, 2023
@stroughtonsmith I like it because it avoids the nested hell that can happen when everything is done by taking children. Flutter does this, and adding stuff like padding to a UI element can easily make a 300 line diff because everything's been shifted forward a level.
Show threadFilip NěmečekSep 27, 2023
@stroughtonsmith sometimes I think that Microsoft has figured this out with XAML (the separation of UI and logic, base styling similar to CSS) or maybe my memory is just bad 😅
Show threadDominic HoptonSep 27, 2023

@stroughtonsmith I find the same problem with most ‘builder’ or ‘fluent’ API styles. It just _looks_ weird.

I find SwiftUI’s version even weirder since it *feels* like it’s creating russian dolls of containers, but it’s not… it’s knocking up some state to be processed after the fact in lots of different ways.

Show threadAxel Le PennecSep 27, 2023
@stroughtonsmith I extract every subview in property variables or func in my Views to clean the mess. It really helps me read the code and split the visual aspect from event handling too. Or I create dedicated “dumb Views” for the visual part: great to use with Previews.
Show threadChris WagnerSep 28, 2023
@alpennec @stroughtonsmith big fan of dumb views with dumb properties
Show threadSteve TibbettSep 27, 2023
@stroughtonsmith The lack of discoverability gets me. Type `Text("Hello").` and you get hundreds of legal but nonsensical suggestions. I think you could provide passthrough modifiers whose only job was to scope down the results, like `Text("Hello”).events.` and you just get events etc. I haven’t tried it, maybe it wouldn't work.
Show threadMat GaddSep 27, 2023
@stroughtonsmith using custom LabelStyle etc is much cleaner but there don’t seem to be equivalent ImageStyle and TextStyle protocols. Could add extensions or create custom Style implementations I suppose, but yeah – the “right way” should come from Apple.
Show threadTrevor TurkSep 28, 2023
@stroughtonsmith Agree, FWIW this article offers a few possible options for today https://www.swiftbysundell.com/articles/encapsulating-swiftui-view-styles/
Encapsulating SwiftUI view styles | Swift by Sundell

An overview of the tools and techniques that we can use to create a clean separation between our view hierarchy, its styles, and the components that we’re looking to reuse across a given project.

Swift by Sundell