a FRP ember component using redux (yay)

ember-v-next.js

import Ember from 'ember';
import hbs from 'htmlbars-inline-precompile';
import connect from 'ember-redux/components/connect';

var stateToComputed = (state) => {
  return {
    low: state.low,
    high: state.high
  };
};

var dispatchToActions = (dispatch) => {
  return {
    up: () => dispatch({type: 'UP'}),
    down: () => dispatch({type: 'DOWN'})
  };
};

var CountListComponent = Ember.Component.extend({
  layout: hbs`
    <span class="parent-state">{{low}}</span>
    <button class="btn-up" onclick={{action "up"}}>up</button>
    {{count-detail high=high down=(action "down")}}
  `
});

export default connect(stateToComputed, dispatchToActions)(CountListComponent);

@bfitch I think you misread my intent. I gave this feedback to @toranb in order to help him drive adoption, not stifle it or push back on the ideas.

Far from underestimating it, one of my favorite things about Ember is that it has changed pretty radically over the years. I know this because writing Ember code has been my full time job for the past three. And yet, through all that epic change, there has remained continuity. Take Glimmer for example... a revolution in how rendering is accomplished, but as far as how it actually impacted how you write Ember code? Well that was actually pretty minimal. While Glimmer the idea resembles React the idea very closely, Glimmer the API resembles React the API not at all.

Some things, like observers and views had to change drastically because they were simply incompatible with new and emerging best practices. Others, like handlebars templates, had to change very little. So really the question I'm asking is how much are we trying to change because it's absolutely necessary? And how much are we trying to change because that's just the way Redux currently does it?

I wouldn't downplay your or other developers ability to adapt and benefit from new patterns.

Trust me I don't downplay my ability to adapt and benefit from new patterns. That's literally my job description. And I don't downplay other developer's ability to adapt and benefit from new patterns either. Why would I? Adaptability is one of the things I love about the Ember community.

Five years ago client side MVC (backbone) was a brand new thing. If we moved from jquery to MVC/Ember, we can move from two way bindings and inter-component communication to one way dataflow, an event dispatcher and a centralized state store.

Again, I don't have to be sold on the idea, but what I think the community at large does have to be sold on is the breaking changes that have to be made to bring this idea to Ember.

Suppose for a second that there were a car manufacturer from the UK that pioneered an incredible leap forward in engine technology, and a manufacturer in the US wanted to emulate it. If the prototype they were reverse engineering had the steering wheel on the right side of the car, they might be tempted to say "in order to use this new tech, we've got to start putting all steering wheels on the right side", but in truth that's just an orthogonal choice to the core concept that the original manufacturer made that is actually an annoyance in a different context.

@toranb Clearly there are some things that have just simply got to change, but what I'm trying to sell you on is to really distill redux the idea vs redux the API and think deeply about how both parts fit best into Ember. Experimentation with all kinds of different APIs is a really important part of this process. There's no doubt about it, but at the same time, continuity of API is a large part of the stability in "stability without stagnation", and Glimmer is proof that it can be done and done with moxie.

@bfitch I think you misread my intent. I gave this feedback to @toranb in order to help him drive adoption, not stifle it or push back on the ideas.

This was poorly said on my part. I can totally see how you might think of this as pushback on the idea itself rather than feedback on the form the idea takes inside Ember.... especially when you so often encounter knee-jerk reactions to change out there in the wild. I can only assure you that I want to see this work take root.

@cowboyd Thank you for taking the time to respond at length and for clarifying your intent...really appreciate it. I understand were you're coming from much better and am relieved that you don't need to be sold on the value of Flux-y patterns. :)

I am totally on board with your concern to provide the most Ember-like API for these patterns and I agree that API changes should be justified and essential, instead of just ported over. One interesting thing I noticed while working on ember-cerebral was how well it integrates with Ember's existing routes, components, actions, and computed property APIs. The two fit together so well, but it requires learning (and liking) the "other half" of the integration: cerebral.

One interesting case study is vue.js. They introduced pretty much a redux port, but using the current Vue idioms and APIs: http://vuejs.github.io/vuex/en/intro.html.

Vuex is an application architecture for centralized state management in Vue.js applications. It is inspired by Flux and Redux, but with simplified concepts and an implementation that is designed specifically to take advantage of Vue.js' reactivity system.

Sounds like exactly what you (we?!) are advocating.

@bfitch These are great finds. Thanks! They're both great stories of projects adapting new ideas to their own structure and vocabulary and vice-versa. It's clear to me that we're really just at the beginning of this journey, but I'm so looking forward to it.

So who wants to do some elm pair programming with me? It's totallyl the future! http://elm-lang.org
I think most of the smartest nerds have left javascript already.

Also I'm interested in trying to port elm-ui sass to elm. Cut one language out of the picture. Also need to port compass.