-
Notifications
You must be signed in to change notification settings - Fork 43
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
Using with Redux #18
Comments
That sounds like a good change, i'm happy to merge such a PR if it uses state as a fallback as you describe. Can you make a JSFiddle of using react-chatview with redux so i can see the same thing you see, before you start refactoring? |
Here is a Jsbin that demonstrates the basic pattern: https://jsbin.com/tasipi/edit?html,js,output To keep things simple it is not using React but the way it gets props from the redux store in the render method should look analogous. The button callback simply dispatches an action which results in immediately setting isLoadingMore to true (the reducer) and eventually switching back to false (from the epic dispatching another action), no promises involved. I've created a fork with the added prop support implemented and it is working well so far. |
If there are no issues with the new props I can submit a PR to implement this change. |
Yes please |
i really appreciate it! |
Done. The branch has build artefacts so I'm not sure if that will cause a problem. |
Since the onInfiniteLoad callback currently needs to return a promise it seems to be difficult to work with Redux. I've worked around this by passing a deferred with the action but this feels hacky to me.
Has anyone else used this with Redux? We're using redux-observable instead of thunk so there aren't usually any promises to work with.
I think a more idiomatic solution would be to support tracking isInfiniteLoading with a prop rather than state so that the component can be told when loading is complete externally. The current behavior can be maintained by using a prop to switch between the current promise based + internal state behavior and being prop-driven. Backwards compatibility is simple by keeping the current behavior the default option.
The text was updated successfully, but these errors were encountered: