Extensibility of Features & Breaking Changes

[JacksonUtsch]

I've utilized TCA features inside isolated packages. A number of executables will depend on these. If wanting to add any functionality (actions) to features it will cause a breaking change. This being the nature of Swift enums, have others experienced this too?

If Swift had non-exhaustive enums this could help quite a bit. Especially with typed Failure cases. There are C enums that are non-frozen but don't offer associated values so not a perfect substitution.

Is there a good way to circumvent breaking changes if wanting to make changes to features that multiple apps use?

---

An example of a shared bluetooth package:

public struct PeripheralType {
  public init() {}
}

public struct Peripheral {
  public var type: PeripheralType

  public init(type: PeripheralType) {
    self.type = type
  }
}

Where in the 1.0.0 release of a BLE package the action is defined:

public enum BleAction {
  case scan(PeripheralType)
  case connect(Peripheral)
  case disconnect(Peripheral)
}

Then if a small addition is added to the action it causes a break to the package for users needing a major version change and a migration guide.

public enum BleAction {
  case scan(PeripheralType)
  case connect(Peripheral)
  case disconnect(Peripheral)
  case scanAndConnectFirst(PeripheralType)
}

An idea would be to use an alternative to enum but you cannot pattern match a function to gain associated values.

struct BLEAction {
 var id: Int
}

extension BLEAction {
  public static func scan(_ type: PeripheralType) -> Self {
    .init(id: 0)
  }

  public static func connect(_ peripheral: Peripheral) -> Self {
    .init(id: 1)
  }
}

func reduce() {
  let action = BLEAction.connect(.init(type: .init()))
  switch action {
  case .scan(let type): // Error
    break
  case .connect(let peripheral): // Error
    break
  }
}

Perhaps the loss of an associated value is what alternatives to enum would lack?

[stephencelis]

@JacksonUtsch Can you flesh out your post a bit more to more fully explain what you're trying to solve and what specifically is preventing you? A code sample demonstrating the limitation would help. Also, what in particular about enums is limiting you, why/how, and what is preventing you from using something other than an enum to work around the problem?

[JacksonUtsch]

Hopefully this example helps?

[mbrandonw]

Hi @JacksonUtsch, my first impression of your code is that this seems more like a dependency than a reducer. I think this becomes clear once you see that the actions aren't driven off of things the user is doing. Instead they should probably be endpoints on a dependency.

We have a bunch of examples of this kind of dependency in the repo too, such as the audio recorder, speech recognizer, web socket, and more.

Have you tried that approach?

[JacksonUtsch]

@mbrandonw Perhaps I could have illustrated the example better. This would and does require a BLE dependency. The idea is to encapsulate all the logic that would be reused into a feature; the state, the actions, the reducer. In which, a logic rewrite would not be required for each application using this feature.

Example of the universal ble state.

struct State {
  /// Peripherals discovered by the Central Manager
  public var discoveredPeripherals: Set<Peripheral>

  /// Peripherals currently connected
  public var connectedPeripherals: Set<Peripheral>

  /// The duration of a scan
  public var scanDuration: Double

  /// The duration a connecting attempt should take
  public var connectDuration: Double

  /// Indicates scanning in-progress
  public var scanning: Bool
}

[JacksonUtsch]

Although like you said, if it could be modeled as only a dependency that would be beneficial, especially now with the more implicit @Dependency usage. (prior to, Environment's would more likely break with client changes)

I have modeled many dependency packages as Feature's where they have associated logic. With such, being more useful and complete.