A proposal for render

[goatslacker]

No description provided.

[goatslacker]

@taion

[taion]

Sorry I've been reading through this in parts but I'm jet lagged/feeling like crap -

First question is that I notice you still separate out the "remote get" logic from the "local get" logic, i.e. resolveAsync v reduceProps - do you want to eventually add the convenience bit that merges both of those?

[taion]

You shouldn't be able to import context connect like that - this is only working because of Babel's fallback for when you have a single default export.

EDIT: Fixed typo.

[goatslacker]

Ok, fixed this. Will push update soon.

[goatslacker]

Regarding resolve vs reduce, yes they need to be separated. Resolve is just about resolving a set of promises before the component is even rendered. Reduce is about what gets sent down to the component.

The key here is flexibility. Often though you may just want to resolve all the props and send them all down. In that case you can write easy getters for that task.

[taion]

I still think it almost always makes more sense to combine the two. I'll prototype something up real quick.

How do I, uhh, run this? I get TypeError: Cannot read property 'iterations' of undefined if I do npm run build after installing iso and axios when I hit localhost:3000 after running babel-node server.js.

[taion]

Something like

        return Promise(resolve => {
          setTimeout(() => resolve(this.render(alt, Element, info)))
        });

no?

[goatslacker]

yeah, fix this line in order to fix the error above!

[goatslacker]

this isn't necessary actually, im doing this to have a better separation because if a react component throws it'll instead be handled by the Promise which I don't want it to be.

[taion]

Well the problem is that you resolve the promise with the time out rather than something that unwraps into the expected object.

[goatslacker]

right, that's silly. What you wrote above should work.

[goatslacker]

I don't think they should be combined because they're two different things. Combining them would end up looking a lot like react-resolver/react-transmit but with a flux backing.

Plus this complicates a few things, like whenever a store changes we have to keep track of what's been fetched/what hasn't so we can pass those props off to the component.

[taion]

@goatslacker

That's exactly the approach that Marty takes, though, and I think it's really valuable - it cuts down on a lot of boilerplate and makes the relevant async fetching code much easier to write.

You don't need to explicitly track completed fetches, because those should be handled via the local hook. You do need to explicitly track pending and failed fetches, but it's not so bad.

For the average use case where you want to fetch the data once and keep the data around, it's really nice and expressive. I think the only additional thing you might want to do is potentially refresh the data from the client-side in certain instances.

[goatslacker]

@cpsubrian had an idea to determine what needs to be passed through by looking at propTypes

[taion]

I'm going to do my best to prototype something up as a PR to this branch tomorrow just as a PoC. Didn't get a chance to do so tonight.

[cpsubrian]

Note that you could support React.PropTypes.shape to even deep-dive, though that might be getting out of control :) Also, if you're using more than just the keys of the propTypes you'd need to have hooks so people using custom types can implement their own logic. For example, I use react-immutable-proptypes.

[goatslacker]

container component's propTypes

[taion]

ref #400 - a basic prototype of the resolver/transmit-style API, which I think is actually sorta nice. It also doesn't use React context at all, which is a somewhat orthogonal change.

[taion]

This is probably not the ideal way to handle timeouts - seems like it'd be better to Promise.race for the timeout, or have a flag on the DispatchBuffer that gets triggered by the timeout firing; otherwise you end up waiting unnecessarily long.