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);

The main issue that I see with this is that it represents a nearly complete departure from the way people normally write Ember components. I look at this code, and there's very little that I can grab onto as an Ember developer that will leverage my hard-won understanding of the framework. There is a natural contour to a component that is instantly recognizable to even beginner Ember devs that is just not here.

The challenge is how close can you be to that natural contour, while still introducing the powerful new tools. If you can do that, it has several nice effects. The first is that your buy-in is very low, because people can see "oh, I change this way here and I can get started" vs "oh man, I have to learn a whole new way and write a whole new style". Also, if the style is similar then the buy-out is lower too because if the change is incremental rather than revolutionary, I can always experiment with it and then back out if I don't like it. And of course, a cheap cost of buy-out means an even cheaper cost of buy-in because folks are more likely to experiment with and introduce things that are inexpensive to back away from.

I'd try and push it in that direction as far as you can reasonably take it. Just spitballing, but what about:

export default Ember.Component.extend(ReduxConnect, {
  actions: {
    up() {
      dispatch({type: 'UP'});
    }
    down() {
      dispatch({type: 'DOWN'});
    }
  }
});

Any Ember dev will instantly glom onto the structure of that component and fill in the roles that each bit of code is there to play.

I don't know how feasible that example is, but the point is that actions are already a concept in Ember, so you don't have to fight to make people understand what they are and what their role is.

It boils down to this. The shared understanding that already exists in the tens of thousands of minds that form the Ember Community is a powerful platform for building your ideas on. I'd try and use as much of it as possible.

Totally agree with your comments about how it's not familiar and almost everyone I speak with in the ember community agrees with you 100%. That said, I personally think the main benefits of ember can be found outside of my actual component implementation (read: JavaScript code).

• ember addons - these are still plug n/play because underneath the redux "mixin" or "connect" code I'm using plain old computed properties /actions
• ember-cli and all the build pipeline tooling
• pods for project organization -files are in the same spot and named the same regardless of project
• the best router in JS land / amazing component story / glimmer 2 / fastboot

All that to say... I'm not expecting everyone to jump up and high five me right away. This pattern is something I'm experimenting with to see what I like /don't like about "functional" code leaking into my ember apps. I'm working up a talk now labeled "functional core, imperative shell: redux and ember" (title stolen from the great Gary Bernhardt).

https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell

When I watched his video years ago I remember thinking to myself "this is awesome but no one will ever build apps like this". But then I started looking at my recent ember code (with redux) and wouldn't you know it ... they actually looked like something Gary himself might have done (total guess here - I don't speak for Gary obviously).

I understand the community is powered by "convention" and "familiar looks" but at the same time I'd like to think we are open to experiment with new ideas/ and when something great shows up people will adopt it "because it's great" regardless of how unfamiliar it looked the first time around.

My favorite tag line from ember itself speaks to this

"stability without stagnation" - new ideas welcome :)

@cowboyd You raise a lot of excellent points, but perhaps are underestimating how much Ember itself has changed over the years. When my company pushed our first Ember app to production, components were a peripheral thing, observers were everywhere, views were the bees knees, ArrayControllers were a ok, and Ember CLI didn't exist.

I view @toranb's gist as an extension of where Ember and the frontend community are heading in general. I wouldn't downplay your or other developers ability to adapt and benefit from new patterns. 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.

Fun times ahead, I say! :)

@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.