What are /r/emberjs' favorite Products & Services?

From 3.5 billion Reddit comments

Whatever you do, I'd suggest that the devs don't dive into the RFCs or discussion forums (discuss.ember.js, Slack rooms) too hard for a few weeks, because so much is being proposed and thrown around that they can get even more frustrated.

It's frothy: like a keg in college where you ask for beer, they pour you a cup of foam, and you have to wait for a while to actually get the substance back, or you'll just get pissed at yourself for drinking empty bubbles.

I suggest the 2.0 books, the 1.13 guides (new as of yesterday) and the blog post explaining the difference: http://emberjs.com/blog/2015/06/12/ember-1-13-0-released.html

Once you've all gotten a handle on Ember then the "real-time" discussions are very interesting and you can relate to people's concerns, but until then I'd only use them for asking your own specific questions. Maybe one of us pedantic Ember veterans might tell you it's already been answered somewhere, but with everything moving so fast you're better off ignoring any solution you see and just re-asking.

if you PM me I'd happily chat about Ember (and "stir down that froth"). Unless we find out we're competitors in which case ActiveX is definitely the way to go.

Ember makes it pretty easy to have loading. You can create a global loading template or have separate templates for specific routes or sub routes

http://emberjs.com/guides/routing/loading-and-error-substates/

You could just use any standard ember tutorial and replace the resource path with your api endpoints.

For instance, if you wanted to use the Github api you could do something like this:

Github.Router.map(function() { this.resource("user", {path: "/users/:login"}, function() { this.resource("repositories", {path : "repositories"}); this.resource("repository", {path : "repositories/:reponame"}); }); });

Github.UserRoute = Ember.Route.extend({ model: function (params) {
return Ember.$.getJSON("https://api.github.com/users/" + params.login); } });

If you go to Codecademy and scroll down to apis: http://www.codecademy.com/learn

You can find some open apis that you can play around with.

• I am not the author (he is Balint Erdi), I just bought his book cuz I liked his screencasts :-) I don't think there's a sample chapter, but he's written some articles and has a few screencasts on youtube.
• The whole app is done in ember-cli
• No user auth as far as I can tell (I haven't finished reading the book yet)
• Qunit, he covers both unit testing and acceptance/feature testing.
• He plans to update it through Ember 2.0

I would use ember-data to fetch your data if you're not doing so already. Once you have the data in your controller or component you could just use a computed property to sort it.

I wrote a very simple computed macro addon that is great for immutable sort orders: https://github.com/workmanw/ember-computed-sortby

You can also use the built in sort macro if you want to be able to mutate the sort order (http://emberjs.com/api/classes/Ember.computed.html#method_sort).

No, I'm upset because things stated in several official blog posts have been delay indefinitely.

See: http://emberjs.com/blog/2015/05/24/another-two-oh-status-update.html#toc_routeable-components

> It is extremely likely to land in 2.1, or 2.2 at the latest.

That is one of the reasons I'm upset, because of the routine broken promises.

Routable Components isn't even being worked on, at all. Improved Pods only exists in an RFC.

Ember core team cannot ship features. They create these massive features to generate hype and they fail to deliver. And instead of trying to be practical and deliver things in pieces, they've held back on doing anything. Leaving many of us just hanging in the wind.

I wouldn't recommend using the canary branch. Not for a soon-to-be production ready project.

Obviously converting {{component}} to <component> is trivial. But to avoid rewriting a lot of code, you should use the new get/set properties. In that way you can more easily control the flow of the application. :-)

It's described in the Ember 1.12 release in the third code block: http://emberjs.com/blog/2015/05/13/ember-1-12-released.html

I made a list of some good tutorials. But I agree with babinho, create a few applications. It's the best way to learn.

If you need help feel free to reach out here! Also check the official documentation it's great.

Loading session state before rendering sounds like a job for initializers, http://emberjs.com/api/classes/Ember.Application.html. Call deferReadiness, do your Ajax call, call advanceReadiness in the Ajax callback.

Their aim is to match every Ember native tool to the same version. This means if Ember.js is in 2.4, expect to have an Ember data 2.4 and Ember CLI 2.4 to be released soon.

http://emberjs.com/blog/2015/06/16/ember-project-at-2-0.html

Ember computed properties are very powerful: communities: Ember.computed.filterBy('model', 'isCommunity')

filterBy can take an optional value, otherwise will match the value true.

http://emberjs.com/api/classes/Ember.computed.html#method_filterBy

Geez. Ember documentation is still horribly out of date, it took me way to long to find this, but anyway: You might want to update computed property syntax from fullName: function () { ... }.property('firstName', 'lastName'),

to the new Ember.computed syntax:

fullName: Ember.computed('firstName', 'lastName', function () { ... })

Or even with getter/setter syntax:

fullName: Ember.computed('firstName', 'lastName', { get: function () { ... }, set: function () { ... })

Since the old syntax is planned to be removed. http://emberjs.com/blog/2015/05/13/ember-1-12-released.html

"This also aligns Ember's API with JavaScript getters and setters, and simplifies the path towards using JavaScript getters in Ember 2.0, after IE8 support is dropped"

Beware: this method uses Ember.View, which is deprecated as of 1.13.0. This link might serve as a bit of a guide on how to migrate it toward a component-centric approach.

You can use http://emberjs.com/api/classes/Ember.ObjectProxy.html to solve this. You return the proxy object and then when your promise resolves update the content property of that proxy object.

See http://discuss.emberjs.com/t/how-to-resolve-a-promise-within-a-template/6929/2?u=opsb for an example

> I'm sorry, what? Did I miss something? You better not be messing with me.

HTMLBars landed in the 1.10 beta or, to be more precise, can be used without modifications. The blog post contains the instruction to use it in ember-cli.

http://emberjs.com/guides/configuring-ember/disabling-prototype-extensions/

"This is the extent to which Ember.js enhances native prototypes. We have carefully weighed the tradeoffs involved with changing these prototypes, and recommend that most Ember.js developers use them. These extensions significantly reduce the amount of boilerplate"

The presenter is Joost De Vries https://about.me/joostdvrs. He is a contributor to the Ember-cli project. Thanks to Ember-cli using ES6 module systems, there are no more globals in our Ember code. That's nice and all, but there was an unexpected side-effect in the javascript world. Services like jsfiddle became unusable since they do not support the module system. Services like jsfiddle is important because it lets the open source community quickly demo their frontend code.
He worked together with Alex Peller http://alexspeller.com/ to create Ember Twiddle! It uses github gists along with heroku to create a working ember-cli in the browser.

I figured you were just running your own system built on top of Ember. Unless I decide later to implement something custom on my own, I'm using Slate which is something that closely resembles the Stripe API docs. The Stripe doc, which I love, get recommended as a solid example of good documentation quite regularly.

> As it's a headless CMS [...]

Oh, duh... I don't know how I missed that. I guess it's a little too early over here and I spaced that part out. Obviously you'd be defining all your models so they would be specific to your user and therefor not something you can apply universally to your docs. Don't mind me, just need more coffee I guess haha.

Thoughts on Ember vs React:

I did React for 3 years before I moved to Ember.

&#x200B;

Not even a comparison.

React is a view library, so any project using it ends up creating a bespoke framework each time.

Ember already is a framework so there is a great deal of pre-solved problems that react teams tend to spin their wheels on for a while.

Also, you may be interested in this: https://www.notion.so/Ember-For-React-Developers-556a5d343cfb4f8dab1f4d631c05c95b

Or, more directly: http://handlebarsjs.com/builtin_helpers.html

I used Handlebars in a Grunt workflow for static template compilation to integrate them into CRM/CMS platforms long before moving to Ember, and there's an entire world of Handlebars helpers out there well beyond the core (if, unless, each, et al).

If this information on the Ember Site is accurate, then Ember 2.9 (with Glimmer 2) will be shipped on the 17th of October 2016 (is in beta5 at the moment)

Edit: Added the year for when this post is read far in the future!

It is not a different syntax for observer, it operates on different semantics.

Like React, the new Glimmer engine in Ember since 1.13 has idempotent re-renders via a virtual DOM diff. This new rendering strategy means that every time new attributes are passed into the Component, Ember can diff the changes, re-render the entire Component, and only update the parts that require updating.

When any new attributes are received (they are the equivalent of props in React terminology), the Component's didReceiveAttrs hook (one of many new hooks) fires, and you can handle the changes in there. Unlike an observer, this hook does not watch specific attributes. It will always fire when any one of them changes.

eh, it's just refinements on how view objects are constructed and used. Components are just more isolated and reusable views than Controllers (and do away with the odd Rails legacy of calling views controllers). The interfaces are not so different between the two. As you become more experienced in any Javascript framework, it's simple enough to make the leap from one way of constructing views to another.

You can compare the Controller interface to the Component interface. Many methods and properties are the same. Components add events they can react to.

For now it's an extra layer of complexity to have to deal with both Controllers and Components. But none of the Javascript frameworks have settled on anything that's completely clean, robust and feature complete. They're all undergoing metamorphosis in every major releases to attempt to encapsulate both ease of use, reusability and flexibility.

Read the change notes on the ember site.

2.0 isn't a grand rewrite or anything, it's mostly just a bump in version numbering. Most of the backwards incompatibility comes from removing old cruft in the framework. If you're new to Ember you can start with 2.0 no problem, as long as you're following new-ish documentation.

The only conceptual change between 1.0 and 2.0 is that Controllers are being phased into Components. In 2.0 there are Controllers and Components, in the future there will be only Components (Ember 3.0?). The terminology in Ember is a fairly confusing, but with Controllers being renamed to Components it makes a little more sense?

Ember.RSVP.hash returns a promise:

http://emberjs.com/api/classes/RSVP.html#method_hash

> RSVP.hash is similar to RSVP.all, but takes an object instead of an array for its promises argument. > >Returns a promise that is fulfilled when all the given promises have been fulfilled,

http://emberjs.com/list-view/

List view is for lazily rendering long lists for performance improvements. Never used it but from what I gather, if the item in the list isn't visible then its not inserted into the dom. I had forgot about it and was surprised to see it mentioned in the blog post.

I think that's because of this blog post on the official Ember Blog where Yehuda highlights that the core projects (Ember, EmberCLI, Ember Data) will go hand in hand from this point on. And will have essentially the same versions.

"Starting with Ember 2.0, we will coordinate every release of Ember with releases of the main ecosystem tools maintained by the core team:

• Ember CLI
• Ember.js
• Ember Data
• Liquid Fire
• List View "

Is it me or does the demo have a memory leak? I was watching dev tools and the heap is constantly going up. That's no bueno. I'm still very excited though.

Edit: it's a known issue: http://emberjs.com/blog/2015/05/05/glimmer-merging.html

The best place to learn all this stuff is the official blog. Every time they do a new release (every 6 weeks I believe) they post a blog with changes, and often go into a lot of detail about what went into those changes. The blog is here:

http://emberjs.com/blog/

and specifically the post about HTMLBars and the ember-template-compiler.js file is here:

http://emberjs.com/blog/2015/02/05/compiling-templates-in-1-10-0.html

I tend to distinguish between the tutorial and the rest of the guides.

Which events aren't firing on touch?

Views are still part of the framework, and are used in a lot of production code, so I personally think it's helpful to have them detailed in the guides. When they're deprecated, notes will be added, and the tutorial will be updated. Probably just fold most of it into the components section.

So yes it is true, setting a computed property will remove the "computed-property-ness" of it. That is, unless you take two parameters into your computed function, if your computed property takes parameters, Ember will instead call your function when 'set'. This allows you to do some really interesting things. I think your problem can be solved like so:

http://emberjs.jsbin.com/ciwifajaze/1/

http://emberjs.com/guides/object-model/computed-properties/#toc_setting-computed-properties

Yes. The fact that Angular would make that kind of change is crazy as there is no upgrade path. So far, there's always been an easy upgrade path for ember apps. (Since 1.0) and from what Yehuda and Tom say, it's going to stay that way.

Many large companies are using it for their large scale long running apps. ZenDesk, Heroku's new dashboard, Vine, Discourse, Square, Yahoo, etc. More here: http://emberjs.com/ember-users/

Those companies aren't planning on rewriting their apps from scratch anytime soon.

Could be the metamorph script tags that are inserted around the pictures: http://emberjs.com/guides/understanding-ember/keeping-templates-up-to-date/

You could try using Ember 1.8.0 beta, which no longer uses these marker tags.

It can be kind of hit or miss. I imagine it's particularly bad when it's not US daytime hours. I think a big issue is that most of the people who are very good with Ember are busy doing stuff like developing Ember, so you're stuck with just a few people active in the chat who can help beyond very basic things.

People can't help you if they don't know the answers. Ember Data is a hot topic, but DI outside of the basic Controller needs API isn't used that much. Routing is in every app, but routing problems can be very simple or very tough to solve, and if you're not an expert, they can all look the same. It's likely people just had no idea how to solve your problems.

The guides are pretty good, and will answer most basic questions if you have the patience to read them front to back. It's a lot, but it's worth it.

If you never got your issue worked out: http://emberjs.com/guides/understanding-ember/dependency-injection-and-service-lookup/

There's a difference between redirect and beforeModel. As I understand from the redirect docs it's called around the same time afterModel is called and I didn't want that behaviour. I wanted to transition as soon as this route gets entered so beforeModel seemed like the best place for this job.

Please do correct me if I'm wrong :)

Surprised nobody has mentioned the redirect hook.

http://emberjs.com/guides/routing/redirection/#toc_after-the-model-is-known

It works the same as the afterModel hook, but semantically it's nice to put your redirect logic here.

hmm. There is this: https://glitch.com/It'll run ember apps straight from github

glitch has some weird UI/UX decisions, imo. so.. maybe that's why it seems less popular.There has been some interest in getting ember support on codesandbox, and.. I even tried to implement it, but they do everything in the browser, and I'm not sure how to translate ember-cli into that environment. (angular has a working implementation on codesandbox... but... it looked super hacky - I didn't spend enough time with it to understand what was going on) :-\

If you console.log out arguments in confirmDelete, do you only get the event object?

I made a quick sample on JSBin, where it seems to work, although this is using Ember 1.13, so it might not be the same still (haven't worked in Ember for a while, sorry).

Is true that the validation should happen in the view. Given that you are free to do whatever you want (and, for example, not use the views at all. Which is my suggestion), why don't you bind values to the controllers and validate them in the views? Using computed properties or observers you can validate the inputs and still keep their states in the controller. I hope this example helps you a little bit more. http://jsbin.com/yubayixeki/1/

I asked in #emberjs and got some advice and clarification.

The best approach here is to hook into ApplicationRoute.renderTemplate() and call with this.render() with the target routes, injecting them into named outlets. You have to first call this.render(); without any arguments to render the application template, otherwise you have nothing to render the other ones into. It's equivalent to calling this._super(); but is more clear.

Using {{render "whatever"}} isn't ideal because it's not properly hooked into the Router; it's more of a low-level call like {{partial}} that probably shouldn't be used in situations like this.

Some example code: http://jsbin.com/xadoyusimave/3/

I'm continuing work on my side-project, Backtest. It's still a small app so I can easily try out and adopt Ember Octane features. My favorite features are definitely element modifiers and tagless components!

Also slowly adopting Ember Octane features for my main app, Sutori. It's a slower process cause it's a bigger and more mature app. For every component that I touch, I:

• convert it to angle brackets (thank you Vim key mappings and ember-angle-brackets-codemod)
• make it tagless
• replace use of jQuery by native DOM API
• turn functionalities that were previously components or mixins into element modifiers. For instance, "focus-on-render" for search fields, "on-click-outside" for modals, "with-tooltip" for showing tooltips,... Really love element modifiers for this sort of stuff.

I definitely thank Ember.js that a single developer can develop and maintain an app with over 600k visits per month and 50k active users.

welcome!

have you seen: https://www.notion.so/Ember-For-React-Developers-WIP-556a5d343cfb4f8dab1f4d631c05c95b ?