Drew Colthorp

I've considered the same thing, and may add it. The only reason I haven't is that it would have to be a macro, not a function. This means you wouldn't...

Ouch. Thanks for the bug report. I'll look into this as soon as I can.

I can see that we may each have differing goals with respect to how we would prefer to integrate this pattern into .net apps. Like @cmeeren, I lean toward an...

Hi everyone! A few points of followup. ### Projections I'm glad you like the projections idea @cmeeren! We've been doing one observe per property, but with a couple of twists...

Ah, sorry. Observe is just what we called Select on our Store implementation (not redux.net). The main goal is to not expose the core `IObservable` directly. I wasn't intentionally suggesting...

For what it's worth, here's a [current snapshot](https://gist.github.com/dcolthorp/0ee87537624c596ccc1d72bffa73387b) of our `Store` implementation, which is built on top of a `Ref` type which implements most of the data management and signals....

I have no problem with that. :-) My aim is figuring out the API I want to program to, not designing an API everyone else should use. I'm happy to...

Hi @GuillaumeSalles, Yeah – my plan is to use `async/await` instead of `yield`, and building toward the power of sagas via `System.Threading.Tasks` and Rx capabilities, as opposed to trying to...

Ah, good question @cmeeren . The store implementation I'm using to explore this idea (not redux.net) statically types actions, and uses `action.GetType()` for dispatch. Reducers and sagas in this formulation...

To be clear – I did not mean to suggest that type-based dispatch should be adopted for this purpose in redux.net. My intent was merely to share an example of...