Connect refactor to use transactional setState()

[slorber]

This is a pull request for #368

Not to be merged yet, as the code is not clean but it's enough to get some feedback, as all the existing tests are passing

[slorber]

This is the only modified test @gaearon but I think it's ok to modify

[slorber]

@tgriesser can you take a look at that plz? I've been able to make the tests pass without using this variable. Is there a missing test-case?

[gaearon]

I think the premise was that if we use defaultMergeProps, we know that it’s not going to be shallowly equal if either stateProps or dispatchProps changed. Therefore not even worth doing a shallowEqual check.

[slorber]

@gaearon I've been able to remove the store subscription here, but I still need to be able to trigger the computation from here, otherwise nothing can be put into state for the first render and we are back to doing the computation in render()

is that ok?

[slorber]

@gaearon did you have time to check my PR?

I've tried to run benchmarks of @mweststrate . Not sure to have done them correctly, but I actually see increased performances :) It's not huge, and maybe I did something wrong during the benchmark.

# Change 1:
- Before: ~50ms
- After: ~45ms

# Add 1:
- Before: ~110ms
- After: ~103ms

Maybe you can run them yourself and confirm?

I've published the benchmark app before and after so that anyone can take a look

[gaearon]

Hey, great work. I’m super busy this couple of weeks so I’ll leave this hanging for now. If all tests are passing and you’re confident about it, we can cut a beta.

[slorber]

thanks :)

I'm going on holiday 2 weeks until the 21 so you will have some time to check the code :)

I'm confident globally but not really about the checkMergedEquals attribute that @tgriesser added. Don't really understand the usecase as all my tests are passing without using that, but it has probably be done for a good reason so...

[timdorr]

Superseded by #416