Add hooks for props, pre-resolve, post-resolve, and rejected

[goatslacker]

Add hooks for props, pre-resolve, post-resolve, and rejected

[ericclemmons]

Wait a tick, isn't this already #39? You just like making issues for me, don'tcha! :D

For my own edification, what's the difference in:

@resolve({
  props: {
    users(props) {
      const url = `https://api.github.com/repos/${props.user}/${props.repo}/stargazers`;

      return axios.get(url).then(response => {
        AltActions.resolved(response.data);

        return response.data
      }, AltActions.failed);
    },
  },
}

(I readily admit I don't grasp the subtle differences!)

[goatslacker]

The difference is that if I have twenty props I'd have to add those handlers to every single one, this centralizes the logic to just one handler.

Not necessarily #39 since that just deals with loading/failed rendering states whereas this deals with resolved/rejected state and returns nothing.

While we're on this topic I'd also like hooks for when before a prop is resolved:

@resolve({
  // similar to shouldComponentUpdate, perhaps you want to conditionally resolve certain props depending on store state or whatever.
  shouldResolve() {
    return true;
  }

  // pre-hook for resolving a prop
  willResolve(prop, value) {

    // if the prop is user then lets check if the store has it first.
    if (prop === 'user') {

      // I hijack the resolver, lets not call my original function but instead use this
      if (UserStore.has('user')) return Promise.resolve(UserStore.getUser())
    }

    // value is the promise, or we can just return undefined and resolver can go on its merry way.
    return value
  }
})

I've updated the title accordingly.

[ericclemmons]

This is how I got around that scenario:

resolve: {
  user: function(props, context) {
    return UserActions.load(context.params.userId);
  },
}

where UserActions has:

load: function(id) {
  return UserStore.get(id) || UserActions.fetch(id);
}

Not saying to do this, as this is a very valid scenario. In my case, I opted to remove as much complexity from the container as possible.

I want to think about all 400 issues you opened today so I can ensure the changes are consistent.

I do like the idea of lifecycle events...

[blainekasten]

I do like this idea also.

[max-zelinski]

@ericclemmons in your example UserActions.fetch(id); returns promise, right? Is that flux?

[ericclemmons]

@max-zelinski Correct. This way, if the data exits, it'll be immediately returned & resolved via UserStore.get. Otherwise, react-resolver will load the Promise returned by UserActions.fetch.

And, AFAIK, anything that follows the Flux uni-directional event flow is considered "flux". You can still use constants like FETCH, FETCH_SUCCESS and FETCH_ERROR behind the scenes. The promise is the only async mechanism that works reliably on the server. (Callbacks do of course, but aren't re-implemented yet!)

[ericclemmons]

Architecturally, this is a bit rough in v1. v2 has a much cleaner solution for handling this that'll come in post-launch...

[livemixlove]

Any updates on this? And another question... should I be using react-resolver, or is something else out there the preferred method? It doesn't seem like the project is being updated much.

[livemixlove]

I'm looking at this: remix-run/react-router@97dbf2d

[ericclemmons]

@livemixlove This project became less useful once the community went all-in on Redux (myself included).

Our production up using react, react-resolver, and react-router (v1) uses the method I indicated above.

But there's another maintainer now that can take a look @ this. The lifecycle thing was always rough to figure out, and frankly becomes cleaner with a single app state (e.g. Redux).

[livemixlove]

This was my suspicion. Thanks for the response!