Add Id to environment transform for forEach about swift-composable-architecture HOT 4 CLOSED

This is interesting to think about! In the reusable favoriting component example the favorite higher-order reducer takes an environment function that can describe a favoriting request given an environment:

This functionality is then combined with an episodeReducer:

With a forEach such as yours above, one could potentially define a favorites as a specialized forEach for favoriting without much work.

I'm trying to think through other use cases and how it affects other versions of forEach (like the one that works with arrays by index and the one that works with dictionaries by key). What could they do if index or key were exposed to the environment part of forEach?

from swift-composable-architecture.

After studying the favoriting I'm wonder that this could be implemented as an alternative to the current forEach. It might make things like grouping downloads easier. If the app was web page like, (I used to work at eBay and old habits die hard) then there are times when you want to kill all the loads from a single page. Having a chained environment would make this easier. It also can minimize use of global queues, such as currently being used in the cancelable functionality. It feels a little odd to have the environment produce effects but then cancel is triggered from the Effect class itself.

I'm not sure if its better to do this or have a concept of path.

from swift-composable-architecture.

@toddwbates We just got a Swift forum that should be nice for discussions like this and allow us to keep GitHub issues focused on bugs. Would you be up for moving the discussion there and closing this out? Would also love to see some motivating examples of this kind of forEach transformation. Maybe with a PR 🤩

from swift-composable-architecture.

Sure, I'll try and get one set up asap.

from swift-composable-architecture.