Move `connect` logic to a Mixin

This is contingent on #39 or something similar.

I think the next logical step would be to move the whole thing to a mixin, keeping the connect function in skeletal form, e.g.:

import ReduxComponentMixin from '../mixins';

export default function connect(mapStateToComputed, mapDispatchToActions) {
  return Ember.Component.extend(ReduxComponentMixin, {
    mapStateToComputed,
    mapDispatchToActions
  });
}

This would be a big win I think because it would allow users to continue using the connect function as advertised, or they could opt for idomatic Ember which I think would greatly increase adoption and decrease churn.

Users could basically do in their component files the same thing the connect function would have done for them, e.g.:

import ReduxComponentMixin from 'ember-redux/mixins/redux-component';

export default Ember.Component.extend(ReduxComponentMixin, {
  mapStateToComputed(state) {
    const { users } = state;
    return { users };
  }
});

[toranb]

@dustinfarris thanks for the discussion regarding the wider topic of functional programing (and asking if it should be required for ember devs who want to adopt redux).

I think the challenge I had with this issue originally is that as the project maintainer my preference for a refactor/or change comes 1 of 2 ways.

1. Someone finds a bug with the existing api
2. Someone discovers a legitimate use case I hadn’t yet considered

In this situation it felt as if you were unhappy with the public connect api and you wanted to change it. And in doing so it’s possible the new component we create as a result would appeal to the traditional ember developer (more generally people who don’t think functional first).

This is challenging for me as I don’t plan to use that api and in turn wouldn’t want to maintain it. I left this issue open in hopes of hearing from others in the community who agreed/ or disagreed about its value. As someone who wants to keep the api surface area minimal and education regarding that api simple, I’m still trying to understand if having more than one way to do the same exact thing is good for the project (functional or not).

[toranb]

@dustinfarris short of asking Lauren Tan to define that already fuzzy term “idiomatic ember” 😃

1. watching the more popular addons of late 2015/ 2016 I’ve seen a trend away from them/ and in turn a rise in functional programming. If you look for the word Mixin in some of the more recent addons you use, it’s likely you won’t see it used much (unless the addon is a ember 1x port/ long lived).

Here are a few that show the migration away from mixins/ toward functions and functional programming for reuse.

https://github.com/DockYard/ember-changeset https://github.com/cibernox/ember-power-select https://github.com/cafreeman/ember-object-update https://github.com/dgeb/ember-engines

1. during my day-to-day work I’ve found that more often I reach for functional composition when it comes time to reuse code. If I’m honest, my c# and java background (read: bias) provided more than enough bad experiences with deep inheritance chaining. Mixins just don’t get a fair shake with me these days (for better/worse).

Ignoring my subjective bias, the functional approach in software does lend itself to more clarity in my experience. When I call a function, I get a result - no side effects (predictable/repeatable). With mixins (from my experience using them in med/large ember projects) you quickly start reaching for some shared state on the component/controller or you introduce some -that others tap into. Over time it’s easy to lose trace-ability regarding “why” something changed/or what one mixin might have assumed about the given state of another (especially because this is all shared mutable state we are talking about)

1. a few months back I started to see both 1 and 2 above as general patterns/trends in the ember ecosystem so I took the question to slack (general channel). A handful of people responded saying they never use mixins/ prefer to share code with anything but. One fairly big name in the ember community (unnamed to protect the innocent) said they were something of an anti-pattern these days.

Although my initial response seemed to focus in on “no mixin -they are dead” the main point I wanted to share was that keeping this addon constrained to “one look” is it’s strategic advantage/ or what sets it apart from the other redux ember addons. I realize not everyone will be happy with constraints /opinions like this but they are at the heart of what people tell me they love most about using it.