Add ability to cache resolved props

[rgerstenberger]

Add ability to cache resolved props

[ericclemmons]

Yep! The best way is to, rather than using Axios directly (or whatever
you're using) is to have a wrapper class (I like to call mine HttpService
or APIService) that caches in-flight requests for you.

I think there are several HTTP libraries that do this already, but that's
the gist of it!

On Tue, Feb 16, 2016 at 7:59 PM Rob Gerstenberger [email protected]
wrote:

I'm hitting a case where I know the data won't change after it's resolved.
Is there a way to cache the result?

It looks like this behavior was removed here: #33
#33

For example here:
https://github.com/ericclemmons/react-resolver/blob/master/examples/react-v0.14/src/components/Stargazers.js#L8-L11

if return axios.get(url).then(({ data }) => data); is always returning
the same data, it doesn't make sense to call the API call on every state
change.

—
Reply to this email directly or view it on GitHub
#103.

• Eric Clemmons

[rgerstenberger]

Thanks for the quick response. I'm not sure that solves my problem. If I used a caching module, it would still make a request on server render, then again on client render. The main advantage to react-resolver is the client bootstrapping. I can't use flux/redux for this particular case.

Unless I'm missing something about http caching (totally possible) how could I guarantee the API call is only made once (on server on first render, client on subsequent router navigation)?

[ericclemmons]

Oh, I misunderstood. I thought you meant just on the client between
navigation attempts.

If you're supplying the payload from the server, the client shouldn't ever
re-fetch the data.

On Wed, Feb 17, 2016 at 12:14 PM Rob Gerstenberger [email protected]
wrote:

Thanks for the quick response. I'm not sure that solves my problem. If I
used a caching module, it would still make a request on server render, then
again on client render. The main advantage to react-resolver is the
client bootstrapping. I can't use flux/redux for this particular case.

Unless I'm missing something about http caching (totally possible) how
could I guarantee the API call is only made once (on server on first
render, client on subsequent router navigation)?

—
Reply to this email directly or view it on GitHub
#103 (comment)
.

• Eric Clemmons

[rgerstenberger]

Interesting. By supplying the data do you mean setting window.__REACT_RESOLVER_PAYLOAD__? The client doesn't refetch on initial render only on state change after initial render.

I may be misusing something somewhere. I'll try to get a simple test case going for you to look at.

[rgerstenberger]

master...rgerstenberger:master

I updated the example to include a button that changes component state on stargazers.

Repro steps:

1. Navigate to http://localhost:3000/pillowsoft
// Client render won't refetch data but you'll see component mount console log
2. Click on button to change state
// Stargazer component does not remount but does refetch data

Hope this helps clarify the issue. Let me know if there's any more info you need or a workaround that I missed.

Thanks!

[ericclemmons]

Oh, you're absolutely right. The data is intentially removed after it's
re-used from the server, since I can't 100% guarantee it hasn't changed.

Let me think on this. I was already hoping to deprecate this project in
favor of a Redux-y rewrite...

On Wed, Feb 17, 2016 at 2:23 PM Rob Gerstenberger [email protected]
wrote:

master...rgerstenberger:master
master...rgerstenberger:master

I updated the example to include a button that changes component state on
stargazers.

Repro steps:

1. Navigate to http://localhost:3000/pillowsoft
   // Client render won't refetch data but you'll see component mount console log
2. Click on button to change state
   // Stargazer component does not remount but does refetch data

Hope this helps clarify the issue. Let me know if there's any more info
you need or a workaround that I missed.

Thanks!

—
Reply to this email directly or view it on GitHub
#103 (comment)
.

• Eric Clemmons

[rgerstenberger]

hahaha ok ok. In the meantime would you accept a PR for something like this?

@resolve("stargazer", function({ params }) {...}, {cacheResolvedData: true})

EDIT: Ignore this, workaround below.

[rgerstenberger]

Here's my workaround:

let cachedData = false

@resolve("someProp", function () {
  if (cachedData) {
    return cachedData
  }
  ... api call
})
class x extends React.Component {
  componentDidMount() {
    cachedData = this.props.someProp;
  }

I think this will work everywhere I need it to. Looking forward to seeing a redux-y rewrite :)

[bradbarrow]

I'm finding I'm experiencing the same issue.

My resolves are not re-run client side after having run server side, but they DO re-run upon any re render in the client.

Of course, one can implement our own solution as you did @rgerstenberger but I wonder if there's a preferred way / built in way? Perhaps this could be documented?

Full disclosure, I am using Redux in my resolves. They just dispatch a redux action. As you may imagine though, the change in redux state causes a re-render which causes a re-resolve which causes a re-dispatch and so on

Is the best way forward here to explicitly write into the resolve function to check whether the data is already there or not?