Mastodawn

For what it's worth, the solution I found - and which often works for me - was to move the views into a package.

Selecting the auto-generated scheme for the package and viewing the preview that way works a lot more reliably than with the app scheme.

This is quite a big commitment, since anything that the views rely on also have to move into a package, but luckily I tend to factor my code that way anyway, and I was in the process of moving my views across.

This, of course, means that the couple-of-minutes task of making a preview for a view to see if I can figure out why it was drawing wrong has now taken me about three hours.

But hey - that's actually quite quick in my experience of trying to use previews for anything in the real world…

dimsumthinking Dec 8

@samdeane for me what they depend on doesn’t have to move into the package but do have to be visible from the package.

@dimsumthinking yeah 👍.

I've always tended to structure my app projects fairly similarly to @ameahim's ExtremePackaging layout, and so having all my views in a package, and model or other stuff in dependant packages, all comes quite naturally.

I like being able to build and test as much as I can without needing XCode, but making previews more stable is another helpful benefit.

I’d been a bit sloppy with this app and left a lot in the main project, so I’m now paying down some debt :)

Aleahim Dec 8

@samdeane @dimsumthinking Always nice to meet another ExtremePackaging believer. The preview stability benefit is real — turns out giving Xcode less to think about helps it actually do its job. Good luck with the migration — the other side is worth it.

@ameahim @dimsumthinking 👍👍👋

I’ve been organising my projects that way for a few years - or approximations thereof anyway 🙂. I like that you’ve formalised it though.

In the early days of Swift/SwiftUI, XCode could get a bit confused, but it’s generally better now.

On a good day.
Downhill, with a following wind…

dimsumthinking Dec 8

@samdeane @ameahim it paid off big for me during the swift 6 transition. I could do it package by package. Also it’s made introducing other platforms (car play, tvOS, watchOS, app intents , widgets…) or removing them much easier

@samdeane @ameahim @dimsumthinking I want to move my business logic and data model layer into its own module/target/package/whatever. But it's such a big job… :(

(I have a bunch of build scripts and codegen in my main app target in order to bridge my SQL stored procedures to compiled typesafe Swift. There's big decisions about what should go where, too -- should I put mutation procs in the data layer but keep view-subscription procs in with the GUI?)

@amyworrall @samdeane @ameahim @dimsumthinking "my SQL stored procedures to compiled typesafe Swift" triggers interest 🙂

@helge @samdeane @ameahim @dimsumthinking

My talk from Pragma Conf last year has some details! https://www.amyworrall.com/videos/v/pragma-conference-2024-codegen-driven-development

TLDR is, I'm using CG-SQL (or more accurately, Rico Mariani's “Author's Cut" fork: https://ricomariani.github.io/CG-SQL-author/ )

It essentially adds stored procedures and type safety to SQLite, compiles you C entry points to your stored procs, and spits out a JSON file with a bunch of metadata about each one. I take the JSON and build Swift structs and wrappers.

Pragma Conference 2024 - Codegen Driven Development — Amy Worrall

Amy Worrall

@amyworrall @samdeane @ameahim @dimsumthinking Almost sounds like Lighter ;-) I'm going to have a look tomorrow.

@helge @samdeane @ameahim @dimsumthinking Lighter is on my list of resources, but until now I didn't know it was you!

I've got a slightly different slant; I have the Swift code able to call stored procs, and have a struct to hold the 'row’ type for each proc's output (including parent/child joins for nested stuff), but I treat the actual table structure of the db as a black box to Swift -- the Swift code only talks via the stored procedures, forcing all my business logic into sql.

@helge @samdeane @ameahim @dimsumthinking I bet you have a less insane codegen process than me though. I've got a bit of a house of cards by now :)

@amyworrall @samdeane @ameahim @dimsumthinking Lighter can be run as a Swift build plugin, but in real apps I personally just pregen the code every time I touch the schema. (which is so rare, that it doesn't matter to automate that).

@helge @samdeane @ameahim @dimsumthinking Gotcha. Because all my business logic is in cql files, I change it pretty often. I’ve got Xcode compatible dependency files generated by a script to help compile times (although they’re not perfect so sometimes I need to clean build).

In theory I could write my codegen layer again for eg kotlin, run the same business logic code, and just write a lightweight android GUI… not that I have time to do that soon!

@amyworrall @samdeane @ameahim @dimsumthinking I'll have a look at the video, certainly seems interesting. I also do have interest in bridging actual stored procedures (of course written in PL/Swift) in PostgreSQL to Swift clients.

@amyworrall @samdeane @ameahim @dimsumthinking Well, w/o having looked at the stored procedure stuff, I _think_ (not sure) in SQLite traditional "stored procedures" are not really necessary. Since it runs in the same process, you can just integrate your own Swift (or whatever) functions. Lighter currently has this for queries, where you can specify a Swift closure as a where condition and do whatever Swift you want, essentially.

@amyworrall @samdeane @ameahim @dimsumthinking One has to take some mental jumps here coming from the past, but SQLite is just a lib after all, not a traditional database server. Which has a broad set of implications on what you can do and how you structure things.

@helge @samdeane @ameahim @dimsumthinking Agreed. I’m definitely not saying my way is _best_. But the strict separation makes sense to my brain and I enjoy coding in it.