Ember Conf 2018 TP;DG

summary.markdown

About

Here's is a quick-and-dirty summary of all the important things (from the point of view of SONY and PSNOW) that happened at Ember Conf 2018.

References

• nucleartide's notes https://github.com/nucleartide/emberconf-2018

Tom Dale & Yehuda Katz Keynote

The keynote opener was a major overview of where Ember will ship with in 2018 and what the plans are for it in 2019

New File Layout

Starting in most likely 3.4+ of ember-cli, we'll likely see the new file format organization that will move everything into the ui folder like so:

• src
  • services
    • input.js
    • input-test.js
  • utils
    • prelude.ts
    • prelud-test.ts
  • ui
    • components
      • my-btn
        • component.js
        • template.hbs
        • style.scss
      • dog-food
      • component.js

This new format is available already on ember-cli master (aka canary) branch, we can play with it via the following:

npm install -g ember-cli/ember-cli
ember help

to see how you can generate / init with the new format

Ember Testing

• Ember's andThen helper in tests is deprecated in favor of async-await
• To facilitate better understanding of ember's test framework and avoid collision with existing terminology, we have the following renames:
  • Ember's "Acceptance" tests are now called "Application tests" (these are the tests that boot your entire app and have you navigate around)
  • Unit and integration tests for components that connect data together (i.e. react's "Container" or "Delegate" components) are now referred to as "Container" tests
  • Unit and integration tests for components that are purely presentational are now referred to as "render" tests
  • Unit tests for util functions that neither depend on rendering dom nor integrating with the rest of the ember environment stay as the only true unit tests

Here are some "rules of thumb" for determining what tests we should be writing:

• Does your test demand external data and injection mocks? You probably want to write a "Container" test
• Does your test demand navigation across routes and checking for DOM presence? You probably want to write an "Application" test
• Does your test render DOM? You probably want to write an "Rendering" test
• Can your test be run without any dependency injection or rendering? You probably can write an unit test

Handlebars and Typescript SUpport

• Ember is whole-heartedly embracing typescript
• Ember is moving towards es6 syntax
  • @computed and @tracked decorators
  • @someProp for passed in attributes
  • Single-Word components with angular bracket components
  • native set and get with just the this.blah = whatever

class OlivePress extends Component { 
  olives: Array<Olive>

  constructor() { 
    this.olives = [];
  }

  @tracked('crushed.[]')
  get leftovers(): Array<Olive> { 
    return this.olives.filter(isTooSmall);
  }
}

Named Blocks

Ember plans on having named blocks like so (see the [rfcs|https://github.com/emberjs/rfcs/blob/master/text/0226-named-blocks.md]):

{{#x-modal}}
  <@header as |title|>
    Header {{title}}
  </@header>

  <@body>
    Body
  </@body>

  <@footer>
    Footer
  </@footer>
{{/x-modal}}

Glimmer Rust Port

Finally, glimmer.js plans on porting over its VM, opcodes, parser, etc., related low-level code into rust and deliver to us via web-assembly. Here's what it will mean for us:

• ember should have a much smaller memory footprint
• if we intend to extend the glimmer syntax (e.g. creating new primitives, further optimization, etc.), we will need to learn rust
• we should find out how well (if at all) playstation supports web assembly as this
  • important if the answer is "not at all" then ember will be effectively EOL'd on the playstation devices for the future

Tobias's Testing Talk

Gave a talk on the future of ember testing. This section wasn't too relevant for us because his talk used Qunit changes while we are using mocha through ember-cli-mocha which will handle all the changes for us.

But the one important take-away is:

Owner Registration and Injection

Right now, all our tests are injected on the this object like so:

describe('blah', () => {
  beforeEach(function() {
    this.register('service:footbarf', FakeFootService);
    this.register('service:legvomit', FakeLegService)

In newer embers, we will use the this.owner object to do both registrations and injections:

describe('blah', () => {
  beforeEach(function() {
    this.owner.register('service:footbarf', FakeFootService);
    this.owner.register('service:legvomit', FakeLegService)

Godfrey Chan's Prying Open the Black Box

Ember Debug Library

Ember has a debug library with methods like assert and debug that will allow us to make assertions within our code and log to the console, respectively. They are removed before the app is shipped to production.

import { assert, debug } from '@ember/debug';

You can write assertions as simple as the example below:

import { assert } from '@ember/debug';  

assert('Must pass a valid object', obj);

Debug statements will be written as any console.log statement using the debug syntax.

import { debug } from '@ember/debug';  

debug('I\'m a debug notice!');

Handlebars Debugger

You can also use {{debugger}} statements in handlebars to toggle elements at certain rendering points.

{{#each items as |item|}}
  {{debugger}}
{{/each}}

When using the debugger helper you will have access to a get function. This function retrieves values available in the context of the template. For example, if you're wondering why a value {{foo}} isn't rendering as expected within a template, you could place a {{debugger}} statement and, when the debugger; breakpoint is hit, you can attempt to retrieve this value:

> get('item.name')

Dan Gebhardt's Future of Data in Ember

@dgeb is apparently working on a large git-inspired approach to organization data and io in javascript, he calls the project [orbit.js|http://orbitjs.com/] and this project meets its first user case in ember-data.

Here's how this could be applicable to us:

• Potentially supports graphql
• Ships with things like batching, versioning, caching, and queueing
• We should probably keep an eye out on his progress as eventually his library may solve a large cadre of problems that we have leftover from our graphql upstream

Marie Chatfield's Ember Events

Marie Chatfield went over a deep dive on DOM events in Ember. Here's the big takeaway:

Don't attach DOM-element listeners:

<button onclick={{action 'myAction'}}>
  blah
</button>

and instead use Ember ones:

<button {{action 'myAction' on='click'}}>
  blah
</button>