Migrating to Uneventful #3
Description
Note
If you are not directly calling APIs exported from the src/signify.ts, src/eventful.ts, or src/cleanups.ts modules, you don't need to worry about any of this: it's strictly for those adventurous souls who've dabbled in those forbidden arts. 😉 If you're just using other parts of Ophidian that happen to use those dark secrets, you should be safe, as I'm not currently planning any specific changes to those APIs. Meanwhile, the to-be-deprecated APIs didn't exist until August of 2023, so likely very few people will be impacted, if any.
Now that Uneventful is available, it's time to begin moving away from the mostly untested and undocumented experimental shims and wrappers that Ophidian has been using as a proof-of-concept for it.
The plan is to begin by tweaking the existing code to wrap Uneventful instead of preact/signals-core and Wonka, so that the existing API of those doesn't break too much. I'm assuming that nobody is actually using the Wonka bits but me, so I'm going to just replace those directly. Uneventful has largely the same operators as Wonka, with a few minor differences. (And some major capability/performance differences under the hood.)
The other place where backward compatibility is likely to be limited is in relation to the job/spawn APIs. Uneventful's API in this area is mostly the same, except it uses a completely different (internal) way of pausing to wait for events or promises. If you've actually written custom stuff based on identifying the current job instance and calling its next/throw/return API, that won't work. But if you're just using when() and until() to pause jobs, then you should be fine with the backward-compatibility wrappers.
I think these will be the biggest places where it's not practical to get 100% backward-compatibility. Most of the cleanups/savepoint stuff should be fine, along with most of the signals-related stuff. Unevenftul does all that, and it's been straightforward making wrappers for the old API so far.
Still, there are a couple things there that will be different. The effect() API will be asynchronous going forward, and may have more restrictions on what you can do in it. That is, the function body in an effect will not execute synchronously the first time it's called, and it may be restricted in what signal/value cells it can write to.
In some ways, this is the bit I'm most personally worried about the transition to, since one of my work-in-progress plugins makes extensive use of effects to define all sorts of interactive behaviors, some of which have tricky timing aspects due to working with Electron webview and frame events. So there's going to be some nail-biting when I go to test that out, for sure. 😉
It's possible other issues may come up, so I'll be tracking the progress here for anyone who wants to follow along, or who has questions about how to migrate their code to work with Uneventful, though at first the answer is going to just be to wait until I put out a release that wraps Uneventful to begin with!