Skip to content

Proposal: change custom dispatcher signature #68

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
gaearon opened this issue Jun 9, 2015 · 6 comments
Closed

Proposal: change custom dispatcher signature #68

gaearon opened this issue Jun 9, 2015 · 6 comments

Comments

@gaearon
Copy link
Contributor

gaearon commented Jun 9, 2015

As rightly noted by @vslinko, it's better to provide getState instead of initialState.

I think I was wrong now when I said this. In fact, I find it now easier to implement composable dispatchers only if each “parent” has the ability to “intercept” both getState and setState, and if the child can “query” the latest state.

I'm going to keep this open for a while, as I'm still not 100% sure which approach is more correct, but I'm leaning towards (getState, setState) => action => () now as the signature for the dispatcher.

@acdlite
Copy link
Collaborator

acdlite commented Jun 10, 2015

We also need to rethink where the state "lives." In the current version, there's no way for the Redux instance to push a new state atom to the dispatcher — for instance, a call to Redux::setState() does not result in the dispatcher's internal state being updated, leading to a divergence.

@gaearon
Copy link
Contributor Author

gaearon commented Jun 10, 2015

The thing is, I'm not sure we want to expose setState at all. If you need it you may as well create a new Redux instance. And you can always provide the initial state for a Redux instance when creating it.

I want the state flow from dispatcher to Redux and never the other way around. This makes it much easier to create custom dispatchers IMO.

@gaearon
Copy link
Contributor Author

gaearon commented Jun 13, 2015

I thought about it a bit more, and the only change I'll probably do here is make setState return the state that was set. This satisfies my use case.

@gaearon gaearon closed this as completed Jun 13, 2015
@emmenko
Copy link
Contributor

emmenko commented Jun 13, 2015

So the signature stays the same (with initialState) and only setState behaves differently?

@gaearon
Copy link
Contributor Author

gaearon commented Jun 13, 2015

Yep.

@emmenko
Copy link
Contributor

emmenko commented Jun 13, 2015

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants