Climbing the learning curve of Ember -- trying an ember-calendar POC -- frustrated

1

I’ve, now, been working on Ember for two solid weeks to learn the it and get some simple things going. I have a decent amount of programming experience (multiple years, multiple languages) and Ember is, well, a mess.

I’ve managed to string together a simple application calling a RESTful service and getting some returns to display. Cool. But, as already said, the documentation is woefully incomplete and misleadingly simple all.over.the.place. Trying to get the ember-calendar addon working in a clean build has been an absolute nightmare… much less trying to actually add it to my other working project.

Or, well, maybe I just over-estimate my capabilities. I don’t know at this point. Here’s what I’ve done.

#Attempt #1:

ember new cal-test
ember install ember-calendar
ember generate template index

###Paste in code as per page:

{{as-calendar
 title="Ember Calendar"
 occurrences=occurrences
 defaultTimeZoneQuery="New York|London|Dubai|Hong Kong"
 dayStartingTime="9:00"
 dayEndingTime="18:00"
 timeSlotDuration="00:30"
 onAddOccurrence="calendarAddOccurrence"
 onUpdateOccurrence="calendarUpdateOccurrence"
 onRemoveOccurrence="calendarRemoveOccurrence"}}

###then:

ember generate controller index

###Paste in code as per page:

import Ember from 'ember';

export default Ember.Controller.extend({
  occurrences: Ember.A(),

  actions: {
    calendarAddOccurrence: function(occurrence) {
      this.get('occurrences').pushObject(Ember.Object.create({
        title: occurrence.get('title'),
        startsAt: occurrence.get('startsAt'),
        endsAt: occurrence.get('endsAt')
      }));
    },

    calendarUpdateOccurrence: function(occurrence, properties) {
      occurrence.setProperties(properties);
        },

    calendarRemoveOccurrence: function(occurrence) {
      this.get('occurrences').removeObject(occurrence);
    }
  }
});

###Build it.

ember build

###See the error page doesn’t render.:

Error: Cannot find module     '/cal-test/node_modules/broccoli-sass'

###Ok, lets install broccoli sass. I’ll probably need ember-cli-sass as well, but lets see.

npm install --save-dev ember-cli-sass

###New error:

app/styles/app.[scss|sass] does not exist

###Fix it:

mv app/styles/app.css app/styles/app.scss

###Add in the style:

app.scss: @import 'addons/ember-calendar/main';

###Add the paint addon:

ember install ember-cli-paint

###Conflict, unable to find jquery: Select Option #1: jquery ^1.11.1

###Content security violations, remove it from package.json

package.json: -"ember-cli-content-security-policy": "0.4.0",

###Deprecation errors: [Deprecated] this.pickFiles is deprecated, please use broccoli-funnel directly instead [addon: liquid-fire] [Deprecated] this.mergeTrees is deprecated, please use broccoli-merge-trees directly instead [addon: liquid-fire]

###Go here and fix it:

https://github.com/ef4/liquid-fire/commit/cbf79b66f31e6bb700a8b417350f283f2a0336db

###Missing modules, ‘broccoli-merge-trees’, ‘broccoli-static-compiler’:

 npm install --save-dev broccoli-merge-trees 
 npm install --save-dev broccoli-static-compiler

###File error:

File: cal-test/templates/application.hbs
TypeError: Cannot read property 'path' of undefined
at TransformLiquidWithAsToHash.TransformWithAsToHash_validate [as validate] (cal-test/node_modules/liquid-fire/ext/plugins/transform-liquid-with-as-to-hash.js:45:15)

###The code in question:

TransformLiquidWithAsToHash.prototype.validate = function TransformWithAsToHash_validate(node) {
return node.type === 'BlockStatement' &&
  node.sexpr.path.original === 'liquid-with' &&
  node.sexpr.params.length === 3 &&
  node.sexpr.params[1].type === 'PathExpression' &&
  node.sexpr.params[1].original === 'as';
};

And, stuck.

Should it really be this difficult / sloppy to get this running from a clean build?

I feel like I’m missing something easy.

#Attempt #2 (works):

git clone https://github.com/alphasights/ember-calendar.git
npm install
bower install

###Still has an error:

DEPRECATION: Using `{{view}}` or any path based on it ('dummy/templates/components/liquid-modal.hbs' @ L4:C6) has been deprecated.

Now, even though Attempt #2 has something up and running, the format of the project cannot easily be used or integrated with the previous work that I did to get my RESTful services working.

It shouldn’t be this hard to do a vanilla application and install an addon, should it?

I wonder how hard this would be in another framework… should I go find out?

Thanks for any comments / help.

2

I have never used ember-calendar but I definitely understand your frustrations. I don’t know much about how Ember addons manage dependencies, but I think that they can pull these in themselves. Some of these sound like issues with the addon itself, not with Ember, so maybe you should open an issue with them.

For adding a preprocessor like Sass, you can just do ember install ember-cli-sass. For managing other dependencies, you can use Bower. The CSP addon doesn’t stop your application from running - it’s just there to help you during development, and it’s pretty useful considering that certain platforms enforce CSP compliance.

Ember seems to be changing rapidly, hence the depreciation warnings. Fortunately, these warnings point you directly to the offending code. If you didn’t write the offending code yourself, then you should point this out to the addon developer.

Just don’t judge Ember by your experience with one addon. It’s no secret that Ember has a huge learning curve and even the initial wall is a tough one to climb, but I think that it has a lot to offer. Other frameworks might be better suited for other purposes depending on what you want to build. I came from Angular 1.x and while I prefer Angular’s simplicity, I didn’t like the way that it handled certain things. Things might be quickly deprecated in Ember, but it’s nothing compared to the change from Angular 1.x to Angular 2.0.

3

This is a problem with the addon, not ember. That being said, the documentation does need work and the core team has gotten serious about keeping the documentation up-to-date.

Now, to solve your problem, you can use a git repo for an npm package. Just run:

~/$npm install https://github.com/alphasights/ember-calendar.git --save-dev

and npm will add the git repo as the source in the package.json file.

4

Fair enough… probably some of my learning curve frustrations boiled over into the calendar poc exercise. I do like the architectural viewpoint of Ember, especially with components. But, shit… the docs just leave out so many details – most importantly, many (especially at the official Ember site) don’t really indicate very well exactly which file they are working in, or that some pre-work that took place.

It would be nice if addons would be required to work in a vanilla build before they are given direct access to the ember install command.

It would also be nice if a dev / learning ember install were created that was annotated and strung a route (static JSON) to a model, to a component, to a template. The todo exercise is nice, but now outdated with since fixtures are deprecated.

Going through the learning, pluralizations, and where they are used, is still one of the most confusing things. Still not sure if they only go from a route to a model or what. Not sure if I need to make a plural model as well as a singular one… Not sure if I need to name my RESTful services as plural or singular always… Not sure how to, really, handle pluralizations that don’t fit the plural model (e.g. the word: “series”). The docs say to add some code – uhm, somewhere, but don’t really say where and I couldn’t get it to work. A nice little diagram for pluralization use would be fabulous.

Lastly, the weird (IMO) JSON returns: { object: {} } or { objects: [{ }] }

I imagine that the reason is for side loading… which is nice, but that one feature adds a ton more complexity to back end services that, sometimes, cannot be changed. No?

Specifying in the model if the return is a side load of multiple other models or a singular object would be great. I’m sure that a lot of consumers of mobile aggregation services would love it.

Anyhow, let me try out your solution and get back to you. Thanks for the suggestion.

5

Have you tried the ember-cli book? I haven’t read it but I’ve heard good things. But, that being said, you’re right about the learning curve. When I started, I wrote the ToDoMVC project every day for a week as a kata. That really helped to experiment with different techniques, etc… The best thing that I’ve found is to look for the solution that requires the least amount of code. That’s usually the ember happy path and it will be maintainable and just work. Also, don’t use observers.

hth

6

I had a lot of the same complaints that you have. The guides made it really hard to see the overall big picture. This post along with this one pretty much single-handedly helped me to actually understand Ember so that the guides finally started to make a little more sense.

Ember sort of “clicked” with me a few days ago after spending a long time trying to wrap my head around it. However, Ember Data is kind of a whole other beast that I am slowly tackling. If you focus on understanding the object model and the overall big picture, you will get over a huge chunk of the initial learning curve. Then you can start diving more into Ember Data.

Some developers are working on revamping the guides, and with some input from newbies, I think that they will be great. You can also make your own suggestions in the guides repo. Just don’t throw in the towel yet - Ember has a lot to offer and once you grasp the fundamentals, the reward will probably exceed your initial frustrations.