Start API change for connect decorator

[Keats]

Start of some work on #1

Rename select to slicer to be clearer (and goes well with the existing variable this.state.slice which is the result of calling slicer

Add binding for action creator, a tad different from what was suggested in the thread:

@connect(
     state => ({string: state.foo}),
     dispatch =>({
        append: (...args) => dispatch(appender(...args))
     })
 )

@connect(
   state => ({string: state.foo}),
   {append: appender} // equivalent to MyActionCreators in a real app (import *)
)

I haven't done merge yet as there are still things unclear imo (what happens if you get several part of the state etc) and I wasn't sure whether I missed something from the discussion so I'll add merge if everything is ok and clear

[Keats]

We should also probably not export the components and only have the provide/connect decorators exposed

[gaearon]

Let's change it to selector. We call them selectors in the Redux documentation, as well as in reselect API.

We can rename slice to selectedState.

[gaearon]

(Either way, slice isn't a public API so we may as well call it anything.)

[gaearon]

Hey, thanks! I intended to start in a slightly different direction.

Can you please completely remove <Connector>?
You would need to move most logic from it inside connect.

After this chunk of work is ready, we can bikeshed on action creator binding a little bit more. :-)

[aaronjensen]

@Keats Not sure if this will help, but here is the implementation I did as a shim from fluxxor to redux to aid in us converting: https://gist.github.com/aaronjensen/95e505cdcbbe9d46019d

This skips the need for Connector and has merge (you can ignore the subscriptions parameter, that's fluxxor specific).

@gaearon one thing we noticed is that there are times when we want to pass the props to the selector function. Can you think of any reasons that'd be a bad idea?

Also, it looks like you envisioned not proxying the props along in the default merge, so your default merge would just be (state, actions) => ({ ...state, ...actions }). Is that right? Or should it include props? (in my experience, if you include props, state should probably be merged after props or confusing things happen with nested containers and liberal {...this.props} passing.

[gaearon]

one thing we noticed is that there are times when we want to pass the props to the selector function. Can you think of any reasons that'd be a bad idea?

You can make your merge powered by reselect as well.. I think. Am I missing something? Then your third parameter can enjoy the same kind of memoization benefits.

Also, it looks like you envisioned not proxying the props along in the default merge, so your default merge would just be (state, actions) => ({ ...state, ...actions }). Is that right?

I'd rather have (state, actions, props) => ({ ...props, ...actions, ...state }). (Thanks for the tip regarding props btw.)

[gaearon]

Thank you for the effort @Keats! I'm closing in favor of #16 because it's more feature complete and already avoids using Connector.