gossi

Early Signature API design:

type Positional<T> = [name: T];
type Return<T> = EmberComponent<{
  Element: T extends keyof HTMLElementTagNameMap ? HTMLElementTagNameMap[T] : Element;
  Blocks: { default: [] };
}>;

export interface ElementSignature {

gossi

Formats

• Component Colocation: HBS + (J|T)S
• SFC: G(J|T)S with template imports
• Merged Component: one JS file with setComponentTemplate and precompileTemplate
• Wire Format: Output of precompile

Processes

Embroider colocation merge

gossi

Plain Business Logic w/ Ember

Business logic as in:

• Commands/Actions: Mutate things
• Queries/Abilities: Questions that retrieve facts

Let's focus on abilities here (would be very similar for commands, too):

Keep business logic in plain js, ok that's easy. Hard part:

gossi

Ember Monorepo with many Addons in v2

With ember addons v2, dummy and addon code are separated. Which allow us to have a package for each and additionally one more packge for documentation, etc.

Simon Ihmig wrote how to migrate a repo for a single addon to a monorepo.

But how organize your projects if this is already a monorepo and many addons are in there? Where to put the test-apps for each such addon?

Idea 1: Addon Project folder, $addon package

gossi

import Component from '@glimmer/component';
import { action } from '@ember/object';

export default class extends Component {
  @action
  doSomething() {
  	console.log(this.args.context);
  }
}

gossi

Idea for Ember Component Format/Syntax

The basis is, turn working and existing html into a glimmer component.

The html might look like this:

<!-- woohoo.html -->

gossi

SFC Glimmer Components

High Level

Follow the concepts introduced with ember octane:

1. html-first: create a .html .hbs file and start writing your html, that's all to get the rudimentary things going
2. native classes: drop off all ember object shenanigan syntax and write native js

Apply these concepts:

gossi

Universal a11y Helpers

Given the WAI ARIA authoring practices tell you quite good how a particular widget shall behave. What - in case you are developing such a widget as a glimmer component - if you want to write tests for them? What if there is an already ready library of tests to use for them? If you as a developer did a good job and have all the markup done properly, the tests can entirely work on the accessibility tree on top of your markup. If not, the tests will fail anyway.

What about having an ember addon, that provides this a11y test library? In case you are developing a new component, you take that library and throw their tests at your code, without ever writing them yourself and be assured your component is a11y compliant. That library would do a service to the whole ember community.

Example

Here is an example, I've just finished writing. It is the first iteration, I found it quite well and useful and lead me to writing this. Basically, I was

gossi

Text w/ Date: <input type="text" inputmode="date">

Text w/ Numeric: <input type="text" inputmode="numeric">

Date: <input type="date">

gossi

import Controller from '@ember/controller';
import { action } from '@ember/object';

export default class ApplicationController extends Controller {
  appName = 'Ember Twiddle';

  @action
  sayHello() {
    console.log('hellooooooo');
  }