Dale Bustad

@everdimension is correct - there should be no measurable performance difference between the two approaches. And, in fact, you could use `Immutable.js` for everything aside from the top-level state container....

Alright, I'm convinced. I'm going to look into what it would take for the data-store to be pluggable, allowing the dev to use the default, immutable.js, or some other alternative.

Hey @bingomanatee! Would you be willing to add a `Related Projects` section to the README, and add a link/description there? Would be great to collect documentation. Side note: I'll be...

Going to close this as resolved. Aside from what has already been mentioned, you could kick off an effect on `componentDidMount`, setup your listener there, and it'll have access to...

Sorry to keep you waiting! Been busy with life, and now with addressing enhancements and bug fixes. But this is a fun subject for me, so I'll definitely revisit.

Confession: I originally passed both `effects` and `state` to each effect upon invocation, with the same thoughts you've expressed here. However, I ultimately removed it since the promise-that-resolves-to-a-function thing is...

@markacola, a PR would be great. I think we'll want a different name though, since "pure" is quite the overloaded term at this point. I assume you're using this `pure`...

Here's what I'm thinking for the middleware. For the time being, this should serve as a work-around for anyone here still wondering how to do this: ```javascript import React, {...

@drcmda, to clarify, does using `shouldComponentUpdate` and returning `this.props.item !=== nextProps.item`. This places the burden on React rather than freactal, but the performance characteristics should be the same (I think)....

@alex-haproff, your issue is slightly different, and I'd like to provide a friendly interface to do what you want. You can already do that somewhat by specifying state keys to...