ctrlplusb / react-jobs

Asynchronously resolve data for your components, with support for server side rendering.
MIT License
166 stars 34 forks source link

How to attach same work function to multiple components #19

Closed djgrant closed 7 years ago

djgrant commented 7 years ago

Am I correct in thinking that the library currently doesn't have a mechanism for attaching the same work function to multiple components without causing it to be resolved multiple times?

Rather than creating a jobs state of:

jobsState: {
  1: { result: 'result of work' },
  2: { result: 'result of work }
}

is it possible to produce this:

jobsState: {
  workKey: { result: 'result of work' }
}

I reviewed the example using react-jobs wth redux-thunk in https://github.com/ctrlplusb/react-universally/blob/feature/redux-opinionated/src/shared/actions/posts.js#L15.

I'm guessing the point of this approach is to run that work function just once.

However, that seems to miss out on the one of the main advantages of this library, which is its ability to resolve data dependencies at a component level. Pushing that data into the redux store encourages resolving at the route level and for developers then to access the data via the store i.e. not by declarative data fetching.

ctrlplusb commented 7 years ago

Hey sorry I have been cracking with client work so haven't been able to give your queries some good time.

A quick one for this one though....

I think if you reuse the higher order function then you should get the behaviour you desire.

const withSharedJob = withJob(() => ...)
withSharedJob(CompA)
withSharedJob(CompB)

Let me know if it works! :)

djgrant commented 7 years ago

That's the direction I've started going in; I'll share what I come up with!

Initial thought, wondering if a middleware layer in react-jobs could provide a generic solution for caching, batching etc.

djgrant commented 7 years ago

Using the example you gave I found that re-using withSharedJob would result in the same data being resolved multiple times on the server. I got around this by putting redux in the middle as a kind of cache (pretty similar thing to what you've done in react-universally) and actually in the end I found using just redux one it's own with a light touch HOC was enough for now.

ctrlplusb commented 7 years ago

Thanks for the update.

Sorry, I haven't had much time of late to give to this project, but I am going to book in another session with it soon. 😀

ctrlplusb commented 7 years ago

I may actually create a redux-jobs wrapper around this library as it will be such a common request/use-case. May look to your own lib for inspiration. 😀

ctrlplusb commented 7 years ago

Closing this, as with current API specification this is expected behaviour (i.e. multiple resolves)