Have you considered making actions execute sync

[zoechi]

by making the StreamController sync?
In the Flux docs they mention that the actions should be sync and that they are async makes especially testing cumbersome, but also some code where I have more than one action where the later ones depend on the previous one to have completed.
If reducers have no side effects besides updating the store, there should be no need to execute them async.

Are there other ways to ensure the reducer for an action was executed than listening for store changes?

[davidmarne]

This is an interesting issue, and it's one that I have already been considering.
I 100% agree that the actions should synchronous. I wish I would have written it that way to start. I dunno what I was thinking 😞

However, simply changing this may cause existing code to behave differently. For example say you have:

int getCount(store) {
  print(store.state.count); // prints 0
  store.actions.increment(1);
  print(store.state.count); // would print 1 if actions were sync, 0 if async
  return store.state.count; // would return 1 if actions were sync, 0 if async
}

this function would return 1 when actions are synchronous and 0 when actions are asynchronous.

So the way I see it there are 3 options, all of which kind of suck:

1. Just make the change, upgrading consumers may see issues.
2. I make another major version bump after I change it, which could avoid breaking any consumers. However, even then there would be no static analysis issues to warn upgrading consumers of the changes. People would have to read the release notes to find out what changed.
3. Make an optional param to the store, where if set to true, actions would then be synchronous. This would prevent anyone from breaking, but its a bit annoying to have to add that. Sync should definitely be the default.

I'll try and get this addressed in the next few days. I'm not yet sure which option I will choose.

[zoechi]

Glad to hear.
I would make 2. with an optional parameter that allows to set async to true to opt into the old behavior.
Users would still need to read the release docs though.

[zoechi]

@davidmarne I saw you already made a PR but didn't publish it?
Do you have 2nd thoughts or did you just not have time yet?

[davidmarne]

Sorry, I have one project i normally pull things into locally and test with before publishing, especially with major releases. I just haven't get a chance to do that yet, but I can today

[zoechi]

Sounds great! I mostly wanted to know what the status is.
I didn't mean to push, but I am also eager to get that change because I think it will make my code a lot easier.

An unrelated question.
Is there something like combineReducers?
I don't even know if it would do anything useful for me, but I have seen it mentioned in other implementations several times and now I'm curious if I missed something.

[davidmarne]

So combineReducers in js redux serves the same purpose as combineNested in built_redux.
For example, in js you may have

combineReducers(todos, counter)

combineReducers takes the reducer functions, and it will create a state object at runtime that looks like:

{
  todos: ...,
  counter: ...,
}

Since dart is typed, you must define you model first. So you define your state model like so:

abstract class State implements Built<State, StateBulder> {
  Todos get todos;
  Counter get counter;
  ...
}

then to register reducers for todos & counters separately you would do

Reducer<State, StateBuilder, dynamic> createReducer() => (new ReducerBuilder<State,StateBulider>()
  ..combineNested(todosReducer) // reducer that rebuilds todos object
  ..combineNested(counterReducer)).build() // reducer that rebuilds counter object

[zoechi]

I see. Thanks for the explanation!

[zoechi]

fixed by #37