tomdale

WARNING

This gist is outdated! For the most up-to-date information, please see http://emberjs.com/guides/routing/!

It All Starts With Templates

An Ember application starts with its main template. Put your header, footer, and any other decorative content in application.handlebars.

<header>

tomdale

Read-Only

An important feature for Ember Data is providing helpful error messages when your application tries to do something that is forbidden by the data model.

To that end, we would like for the data model to be able to mark certain records, attributes, and relationships as read-only. This ensures that we can provide errors immediately, and not have to wait for a return trip from the adapter.

This also means that the adapter does not need to handle the case where an application developer inadvertently makes changes to a record that it does not conceptually make sense to modify on the client.

Requirements

tomdale

Networking in Ember

Motivation

Most client-side applications need to fetch data over the network. In the Ember.js ecosystem, many developers use a high-level abstraction, like Ember Data, that standardizes network access via an adapter pattern.

For those who want more low-level control over data fetching, it is

tomdale

import Component, { tracked, action } from '@glimmer/component';

export default class extends Component {
  @tracked count = 0;

  @action increment() {
    this.count++;
  }
}

tomdale

{
    "$schema": "http://json.schemastore.org/vsls",
    "gitignore":"none"
}

tomdale

import Component, { gbs } from '@glimmer/component';

export default class extends Component {
  static template = gbs`
    <h1>Hello {{this.world}}</h1>
  `
}

tomdale

Forwarding Named Blocks in Glimmer

Use Case

A component that "forwards" passed blocks to a child component. For example, imagine we have a component called MiniCard that accepts a named block called header. It is invoked like this:

<MiniCard>
  <:header>
 My Card

tomdale

Component Lifecycle Hooks Survey

Most Ember developers are familiar with component lifecycle hooks, like didInsertElement, willDestroy, etc.

As we think about future APIs for Glimmer components that improve on lifecycle hooks, we want to make sure that we're providing abstractions that are simple, performant, and ergonomic, while nudging users towards good patterns and away from potential footguns.

tomdale

import Timer from 'simple-timer';
import Component from '@glimmer/component';
import {  } from '@glimmer/tracking';

export default class TimerComponent extends Component {
  constructor() {
    // Mark the timer as "untracked" (i.e., we're asserting
    // that timer contains no interior tracked properties at all).
    // This function gives us back the timer as well as a callback
    // function to call when any interior mutation may have occurred.

tomdale

export default Ember.ArrayProxy.extend({
  localStorageKey: null,

  init: function() {
    var localStorageKey = this.get('localStorageKey');

    if (!localStorageKey) {
      throw new Error("You must specify which property name should be used to save " + this + " in localStorage by setting its localStorageKey property.");
    }