Obsolete Coordinator

[ra1028]

Description

The Coordinator API had greatly increased the complexity of the internal code compared to its low utilization, so we should be discontinuing it in this version.
AtomEffect, which is introduced in this version, covers the main uses of Coordinator, and it should be possible to make other uses of it work the same way by using an object managed by separate atom.

[rasberik]

Gimme-gimme

[strangeliu]

I had to say i just miss the Coordinator API. : )
IMP, The SwiftUI like API

func makeCoordinator()
func make(context: Context)
func update(context: Context)
static func dismantle(context: Context)

is really a good and clean design.

While working with the new AtomEffect API, I noticed a lifecycle-related pattern that might benefit from discussion regarding API design ergonomics.

The Pain Point:
For atoms requiring setup/teardown logic (e.g., BatteryStatusAtom), I'm forced to perform side effects in defaultValue (enabling battery monitoring) which violates the purity expectation of this function. Ideally, initialization logic should have a dedicated hook (similar to Coordinator's make in SwiftUI).

Example Implementation:

struct BatteryStatusAtom: StateAtom, Hashable {
    func defaultValue(context: Context) -> Float {
        // ❌ Side effects don't belong in a pure function
        UIDevice.current.isBatteryMonitoringEnabled = true
        return UIDevice.current.batteryLevel
    }
    
    func effect(context: CurrentContext) -> BatteryObserveEffect {
        BatteryObserveEffect()
    }
    
    class BatteryObserveEffect: AtomEffect {
        func released(context: Context) {
            // ✅ Proper cleanup location
            UIDevice.current.isBatteryMonitoringEnabled = false
        }
    }
}

Proposed Solution:
Would it be feasible to introduce lifecycle methods like willCreate/didCreate in AtomEffect,

This could make side effect management more intentional while preserving defaultValue purity. I'm curious to hear your perspective!

[ra1028]

@strangeliu

I believe that the coordinator's make was also not a good place to make side effects.
Anyways, adding one more effect function to the AtomEffect that's called before the value creation makes sense to me.
Can you please issue a feature request so I don't miss it?