I’m definitley starting to get the hang of SwiftUI at least a little bit. I’m a little more comfortable now with what should remain within the bounds of the declarative framework, and what needs to be abstracted out to functions, for example. The sample code projects initially left me feeling (apparently wrongly) like I could just stay 100% in that framework and just build all sorts of clever in-line logic, but once it gets to a certain point of complexity, you have to bounce from SwiftUI to Swift, if that makes sense, to provide the appropriate inputs so that the framework can just focus on rendering.

In my project, the idea is that I’ve got a JSON structure of related articles which can be sorted in different ways and then displayed by the SwiftUI framework. SwiftUI has a really nice ForEach wrapper that you can use to build navigation lists, and conditionally display different elements in the list item views: in my case, I’m basically giving a headline and a date, and then color-coding the items based on whether they’re standalone articles (no ancesters nor descendants–yet), or if they’re in a family, whether they’re the newest,, oldest, or somewhere in between. I’m also providing an option to allow people to switch between stand-alones and the full list, and there’ll be more navigation options later.

So at first I set up that nice ForEach structure and tried to do all sorts of logic to determine the relationships and manage the display at the same time, and SwiftUI was basically screaming at me, “NO! I JUST WANT THE DATA, ALL PREPROCESSED, AND I’LL HANDLE IT IN A CONCISE WAY!!” Once I finally listened to what it was telling me, I changed the ForEach data source from being a super-complex closure to a call to a function that combed the data and returned an array that could be easily rendered in a number of ways.

Add a state variable to control whether the view being requested is to show all content or just the standalones, a little logic in the array parsing function, and with just two lines of change (adding the state and the toggle button) in the UI code itself, I’ve got a beautifully animated transition between the filtered and unfiltered view.

Also, I did all my initial work with the system rendering in an iPhone XR view. I worried I’d need to do something special to get the split navigation view working on an iPad, but adding that test in, Just Works®. In landscape and portrait modes. No brainer, totally awesome.

This week, I’m going to start working on a system for adding new (standalone and child) articles. Next week I’m on vacation from my day job, so I’m hoping that I can start some serious work on the back end. I’d built something for the web version that I kind of liked in Node, but I’m thinking seriously about ditching the server and going to CloudKit. We’ll see.

And finally, I’m thinking about alternate names for the app. “Cool Takes” would position it in contrast to the “hot takes” that pundits make on all sorts of topics which are important now, but those are rarely revisited. “Refried” crossed my mind as a reference to the folks over at Mueller, She Wrote, who are constantly “putting beans” on topics that need to be revisited, and have occasionally called those revisits “refried beans”. I’m also a longtime reader of Daring Fireball, and I like his use of the term “Claim Chowder”, so it crossed my mind to use the name “Chowder” as well. That said, for the moment, it’s still GAN, or Gently Aged News. Suggestions welcome.