Resolve multiple props with one callback

[nettofarah]

Resolve multiple props with one callback

[ericclemmons]

Why not do:

@resolve({
  propA, function() { ... },
  propB, function() { ... }
})

That's what's happening internally:

react-resolver/src/resolve.js

Line 10 in b5acd1c

const asyncProps = (arguments.length === 1) ? prop : { [prop]: promise };

💩 on me for not having this in the README or docs.

[ericclemmons]

Misread it. You're right, there's not a way to return an object for multiple props from a single call.

I think this makes sense, especially for something like:

@resolve(function(props) {
  return lookup(props.something).then(result => {
    return {
      user: result.data,user,
      place: result.data.place,
  });
})

This makes sense from a signature standpoint because the props aren't defined until the promise resolves. However, this is a problem because it means the resolver doesn't know if the props are pre-existing or not.

TBH, reducing duplicate in-flight requests should be handled via your request mechanism. Annoyingly, there are few implementations I found of this:

https://github.com/matthiasak/universal-utils/blob/master/src/fetch.js

Or my own:

export default class HttpActions extends Actions {
  constructor(...args) {
    super(...args);

    this.requests = {};
  }

  get(url, params) {
    const existing = this.cached(arguments);

    if (existing) {
      return existing;
    }

    const request = this.request("get", url, params);

    return this.cache(request, arguments);
  }

  cache(request, signature) {
    const key = JSON.stringify(Array.prototype.slice.call(signature));

    this.requests[key] = request;

    return request;
  }

  cached(signature) {
    const key = JSON.stringify(Array.prototype.slice.call(signature));

    return this.requests[key];
  }
  ...

[ericclemmons]

Another backwards-compatible API would be something like:

@resolve(["propA", "propB"], function(props) {
  return promise(something).then((result) => [result.a, result.b]);
})

Because they're positional params, it's basically describing the required response signature should any of the props not exist.

Again, I feel this warrants mentioning...In my own side-projects using Redux (meh), co-locating data requirements via @resolve to their immediate components makes sense & works, but it's difficult to solve the duplicate request issue with Redux & in-flight requests.

If I figure this out, it'll probably solve it for several people.

[nettofarah]

This all makes sense, @ericclemmons.

re: Caching
It is definitely a solution, but it feels a little brittle. Mostly because it adds cache invalidation to the mix.

re: backwards compatible API
I hacked something together that basically just allows you to use a hash as opposed to an array. But I see the value of taking your approach to it.

I'd love to help out and try to come up with an implementation for this last suggestion 😄

My current solution basically hijacks resolve.js and checks if a complex has been returned from Resolver and then just deconstructs it.

Would resolve.js be the place to make this changes? Or does this sound more like something Resolver should handle?

[MatviiStelmakh]

Why not do:

@resolve({
  propA, function() { ... },
  propB, function() { ... }
})

small correction : instead of ,
@resolve({
propA: function() { ... },
propB: function() { ... }
})