Ricardo Mendes

Ember.js documenteur

Read this first

Spawning processes in a portable way in Rust

I’m working on a command-line tool named tool-new-release that automates the release process for the Ember Core Learning Team. It is written in Rust for reasons that I mentioned in “Automating Ember releases with Rust”.

Part of automating the release involves calling the heroku-cli, which I do using std::process::Command. I ran into a small stumbling block, however. Calling the executable directly with std::process:Command was not working when on Windows. So, instead of this:

Comand::new("heroku").arg("auth:whoami");

I had to do this on Windows:

Command::new("cmd").args(&["/C", "heroku", "auth:whoami");

As you can imagine, this raised a bit of a problem. At first I using the cfg macro and two different functions:

pub fn get_env_vars(project: &str) -> Vec<(String, String)> {
    if cfg!(windows) {
        check_heroku_cli_windows();
    } else {
        check_heroku_cli();
    }
...

Continue reading →

Nested components and angle brackets, a sneaky solution

UPDATE With the release of 3.10 you can now use :: for nesting. See bottom of the post.

If you have been following Ember development, you might have noticed that starting with Ember v3.4, you have a new way to invoke components in your templates called angle bracket syntax.

In the new syntax, instead of invoking a component like so:

{{user-profile user=user}}

You can invoke it as:

<UserProfile @user={{user}} />

The angle bracket syntax has the advantage of differentiating arguments to the component, @user, from HTML attributes. To set the class using this syntax, you would do:

<UserProfile @user={{user}} class='profile' />

This presents a problem if you have components nested inside a folder in your project, as angle bracket syntax does not support slashes (/) in the component name. Using the recently introduced let helper and the trusted component helper, however, we can do a...

Continue reading →

To `attrs` or not to `attrs`

The advice to avoid attrs is still relevant as of Ember 2.12, and until angle bracket components are released in Ember.

In this post I will attempt to explain why you should avoid using attrs in your Ember.js application code.

tl;dr attrs is a Glimmer Component thing, and Glimmer Components haven’t landed on stable Ember.js yet.

Two Components

First, a bit of background on why attrs appeared. Currently we have a kind of component that is invoked with handlebars (curly braces), like this:

{{my-component}}

These have been around for a while, so for the sake of distinction we’ll call them Classic Components. Then, in the much mentioned Road to Ember 2.0 RFC and related blog post, a new kind of component was introduced that uses HTML-like invocation, like so:

<my-component>

Previously slated to land on the 1.x series, it has been postponed until some serious flaws are addressed...

Continue reading →

Controllers are dead; Long live Controllers

There has been a concern circulating the Ember.js community about the removal of controllers. In this post I will attempt to demystify what is happening and what you need to do to be future-proof.

Deprecations

Proxying

It is true that the proxying behaviour of controllers (ObjectController and ArrayController) is deprecated. In retrospect this behaviour created more confusion than it was helpful. In a proxying controller if you had {{foo}} in your template, it would first look up a foo property in the controller, and if the controller did not have a foo property, it would then look up foo in the model. ArrayController also had a special feature called item controllers which can be implemented with components instead.

This means that when using Ember.Controller, which does not have the proxying behaviour, {{foo}} is equivalent to {{controller.foo}}. If you want the model’s foo...

Continue reading →

Model inheritance for Ember.js routes

Update 2014-04-01

As of Ember.js 1.5.0 this feature is enabled by default for release builds.

Update 2014-02-10

As of commit b351b4a7c41dbaa5d4b1c5508f02df6b957018c7 this feature is enabled by default. This includes Canary builds.

I’ve just helped push a feature to Ember.js’ master that might help you shave off a couple of lines of code. By switching on the ember-routing-inherits-parent-model feature flag your routes will inherit the model from the parent resource by default.

At the moment resources won’t inherit the model from their parents, but that might change in the future, depending on how appropriate the core team deems it.

Getting the right Ember.js

You will have to grab the build from the Canary page. You can read more about the different build channels in the Getting Started section of the guides.

Enabling the feature

First you should read through the section on the...

Continue reading →

Laravel up and running on Cloud9

Cloud9 running Laravel application

Setting up

The other day I decided to try out Laravel since I kept hearing about it and maintain a PHP website myself. The weekend previous I had developed a small node.js package using nitrous.io, so I figured I’d spare my laptops from the likely scenario of poorly installed dependencies and set out to find a suitable service since nitrous.io does not support PHP.

I picked Cloud9 IDE, having used it previously, and after fumbling a bit I came upon these easy steps to have a working Laravel application:

$ c9pm install php
$ curl -sS https://getcomposer.org/installer | php
$ mv composer.phar ../bin/composer
$ composer create-project laravel/laravel <project name> --prefer-dist
```

In order, they do the following:

* Install PHP;
* Download [http://getcomposer.org/](Composer);
* Move Composer to a path available globally, so you can just call `composer`;
* Create a Laravel project,
...

Continue reading →