GRDBQuery, the SwiftUI companion for the GRDB SQLite toolkit, just hit version 0.4.0.
This new releases introduces a new property wrapper @EnvironmentStateObject that plugs a hole in the SwiftUI built-in State and Data Flow property wrappers. It makes it possible to instantiate an observable object from the SwiftUI environment.
It is a great fit for MVVM applications that want to access their databases through dependency injection. It is such a good fit that the documentation comes with a dedicated MVVM and Dependency Injection article that does not even mention GRDB
The documentation looks really good - well structured, and I like the use of articles to help guide people in common implementation scenarios. If that's what you had in mind when you designed the library, it's good to communicate that.
If people don't like that design, they don't have to use it. The good thing about it just being a companion to your other library is that people can still use one piece while exploring different designs for the other pieces if they want.
Program architecture is one of those topics where I hear people argue both that it's a matter of judgement, honed by years of experience maintaining real codebases, but also that you should totally use <insert buzzword architecture here> and follow exactly this coding pattern because it's the One True Architecture and everything else is horrible and massive view controller and spaghetti code and you're holding it wrong and and and...
You don't just follow a dogma and magically arrive at a "clean", maintainable codebase. The best architecture for a given task often evolves organically, and can depend on what the people maintaining it are most comfortable with! Different teams can arrive at different solutions to the same problems.
I love to point people to the Redux FAQ, which spends a good deal of time encouraging people not to learn redux until they actually start having problems managing state in their applications. That's how people should think - less dogmatically, more like "oh, these are some neat ideas and I can borrow some bits of it, as it suits my needs".
If you think this utility is useful for people who write code in a similar way you do, by all means publish it and don't let anybody suggest you don't understand their idea of whatever architecture. It's a shame because a lot of newer developers who don't have the experience to stand up for themselves get put off by these kinds of bullies, pretending to be intelligent.
Thank you Karl :-) I like my apis to be relaxed, so that I feel unencumbered when I run experiments, debug, check hypothesis, build minor parts of an application that should remain simple. And at the same time I sometimes have to work with architecture-obsessed people ;-) It is my personal interest to ship and evangelize ready-made relaxed solutions that support stringent conventions, so that I do not crawl under a rigid cathedral. Now those conflicting forces make it really difficult to write documentation. In its current state, the doc is probably just a guidance for my future self. I hope it eventually becomes much shorter, and... relaxed :-)
