Create a mixin for data fetching about alt

[ericclemmons]

@goatslacker Any preference on what the end-user API would be? Something like...?

mixins: [
  alt.mixins.asyncProp('myResult', MyAction.fetchResult),
]

[goatslacker]

That's an interesting approach to do it on a per prop/action level. I was thinking of importing an entire store and all of the state gets added in. I don't have any specifics in mind, that's up to debate. Just something that makes sense.

👍 on that API though

[ericclemmons]

Not sure I 100% understand, except maybe if UserStore.getState() return { users: [...], current: { ... }, etc. }, and those were set on this.props for easy access.

Let me know what you have in mind...

[goatslacker]

I don't have anything concrete in mind, just thinking out loud. What I said probably doesn't make sense and needs more thought, your approach is sound.

[mattmccray]

Well, in my projects I use a StoreStateMixin that is used like this:

export var Example= React.createClass({
  mixins: [
    StoreStateMixin( StoreA, StoreB)
  ],

  getStoreState() {
    return {
       fromA: StoreA.getSomething(),
       fromB: StoreB.getSomethingElse()
    }
  }
})

The mixin automatically wires up the Store change events to call getStoreState(), setting the result into the Component's state. Obviously this doesn't take into account async data. Usually I'll make a ActionsA.fetchSomething() call in componentDidMount().

Perhaps something like this could work in statics?

var Example2= React.createClass({
  statics: {
    storesToProps: {

      stores: [StoreA, StoreB], // So change events can be wired up?

      fromA( assignData) { 
        assignData( StoreA.getSomething())  // Gets assigned to this.props.fromA
      },

      fromB( assignData) {
        // If you're using Promises in your action, you can consume them...
        ActionsB.fetchSomething().then(() => { 
          assignData( StoreB.getSomethingElse() )
        })
      }
    }
  }
})

I'm avoiding Promises in this example for multiple reasons including: No shimming required, and no error swallowing.

I'm just kind of "coding out loud" here to keep the discussion going. :)

Thoughts?

[troutowicz]

@mattmccray That approach looks like it could work.

I'm curious though on how a mixin for data fetching would really be any different than just simply executing an action within componentDidMount(). What's the benefit? Aren't we defining data fetching at the component level when we call an action?

[goatslacker]

There may not be much utility to this specially with something like react-resolver but I wanted to open this up for discussion

[mattmccray]

@troutowicz It comes down to resolution of data before or after a component is mounted. With the statics approach, it could be tied to react-router and the component's mounting could be delaying until the required data is available. The mixin approach, which I currently use, doesn't try to fetch any data until the component has been mounted. In my case, I'm using a modified version of react-router's fetchData() in the few places I need to ensure there's data before a route is rendered.

As far as why I use a mixin instead of just wiring it up directly in the component's lifecycle events... Mainly to save me boilerplate. The app I'm using this in is a very large, mostly CRUD app. So there are tons of controller components.

I like the look of react-resolver, but unfortunately can't use it in my project -- it simply has too many dependencies to make a stand alone version (as is).

[goatslacker]

Opened a ticket on that: ericclemmons/react-resolver#14

[goatslacker]

Deferring to #49