Malcolm Jarvis

@mohpor Subscriptions are `weak`, so the block subscribers will be unsubscribed when they're released, so as long as one practices good memory management, there is no need to call `unsubscribe`

One pattern you could use to resolve this would be to store multiple, keyed `Item Details`, and pass the key into the object subscribing to the state when its created....

Heres a little helper you can wrap around your existing reducer, and a protocol for actions to conform to: ```swift protocol IdentifiableAction: Action { var identifier: UUID { get }...

```swift struct AppState { let itemDetailsState: [UUID: ItemsDetailState] } func appReducer(_ action: Action, state: AppState?) -> AppState { return AppState( itemDetailsState: identifiableActionReducer(...) ) } ```

it looks like the arguments are reversed in your definition of `itemDetailsReducer`

@sjmueller Would love for you to share the code for this in #455

Passing these services in manually into middleware is how I handle this. eg: `Store(middleware: [fooMiddleware(dependency: bar)])` One should not be passing this sort of thing into Reducers -- reducers should...

My latest commit here refactors `Subscription`, breaking backwards compatibility. The intention here is to make the Subscription system much easier to understand, code-wise, eliminating a number of confusing code paths...

@DivineDominion I've tried to see if I can get anywhere with your suggestions but I keep running into walls, or the implementation gets confusing enough that its not worth it....

@DivineDominion I've managed to partially implement tree-style subscription (allowing multiple `select/skip/only/subscribe` on a given `Subscription`) (I put a couple `TODO` in the tests) I think that covers _most_ of your...