In the end, I had to rip out Combine from the watch and use didSet and custom handler blocks. While that did work, obviously it's not as full-featured (i.e., you can't debounce). After using blocks, things went back to functioning properly.
Thoughts?
That this is what I don't like about things like Combine...
Now, I'll freely admit that one of the realities of working in DTS is that spending all of your time working on other people’s problems makes it hard to be optimistic about, well, just about anything.
However, the promise of technology like Combine is that it makes code easier to write and maintain by reducing "boilerplate" and "unnecessary" code. The problem with a technology like Combine is that when something goes wrong, it's very hard to figure out what failed or how to fix it.
Unfortunately, the dynamic I've seen over and over again across many APIs designed to make things Better™ is that lots of apps end up falling into one of two "traps":
-
The problem itself is simple enough that the "easy" technology is just making everything more complicated than it needs to be. Relying on an elaborate invisible notification architecture to avoid calling a couple of methods is not a good trade-off.
-
The app is sufficiently complicated that the "easy" technology ends up hiding so much of the app’s logic flow that it becomes impossible to understand how the app actually works.
For the first case, the basic question is simply "does this actually make my app better". If it doesn't ACTUALLY make things better, then don't use it. If you're going to use it, then the "art" here is finding the right balance between the "magic" the API provides and having sufficient architecture that you can "manage" how your app actually works.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware