search

makeomatic / redux-connect

Provides decorator for resolving async props in react-router, extremely useful for handling server-side rendering in React
MIT License
548 stars 66 forks source link

filter-ed promises not being executed in componentDidMount #30

Open shilpan opened 8 years ago

shilpan commented 8 years ago

BEGIN_GLOBAL_LOAD/END_GLOBAL_LOAD are dispatched on the client side even when filter stops the asyncConnect from blocking the render function. However, once the component is mounted, since the redux has saved the state loaded as true, it does not fetch the data. Due to this you have to manually redo the logic for re-fetching data in these instances. It would be nice to have some logic to ascertain that the promise is executed in componentDidMount.

AVVS commented 8 years ago

Known bug, not sure I have time to fix it shortly though

On 16 Jun 2016, at 22:00, Shilpan Bhagat notifications@github.com wrote:

BEGIN-LOAD/END-LOAD are dispatched on the client side even when the filter stops the asyncConnect from blocking the render function. However, once the component is mounted, since the redux has saved loaded to be true, it does not call fetch the data. Due to this you have to manually right in logic for re-fetching data in these instances. It would be nice to have some logic to ascertain that the promise is executed in componentDidMount.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

AVVS commented 8 years ago

You are very welcome to help out :)

On 16 Jun 2016, at 22:00, Shilpan Bhagat notifications@github.com wrote:

BEGIN-LOAD/END-LOAD are dispatched on the client side even when the filter stops the asyncConnect from blocking the render function. However, once the component is mounted, since the redux has saved loaded to be true, it does not call fetch the data. Due to this you have to manually right in logic for re-fetching data in these instances. It would be nice to have some logic to ascertain that the promise is executed in componentDidMount.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

shilpan commented 8 years ago

https://github.com/sageapp/redux-connect/commit/d504ee04b1312a91f04f2af1601f1d5e4539c827 here's a rough draft of how I got this to work

AVVS commented 8 years ago

that introduces another abstraction in the already not too easy to understand code. Ideally I wanted to change the line where it checks for the "load" prop in componentDidMount, but not on the root of the reducer state, but for each prop with "key", but because of that we'll have to make sure that "key" is required for filtering

bobbypriam commented 7 years ago

I've just encountered this today, having just migrated from the unmaintained redux-async-connect@1.0.0-rc4. As such, I reverted back. It kinda sucks, I really wanted to leave redux-async-connect, since it complains that the react peerDependency version does not match, I'm using the latest 15.4.1.

Are the solutions provided not good enough?

Ideally I wanted to change the line where it checks for the "load" prop in componentDidMount, but not on the root of the reducer state, but for each prop with "key", but because of that we'll have to make sure that "key" is required for filtering

^ Is this a feasible solution?

idangozlan commented 7 years ago

is there any solution / workaround for now?