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');
  }

gossi

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

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

Date: <input type="date">

gossi

import Route from '@ember/routing/route';
import { tracked } from '@glimmer/tracking';
import { action } from '@ember/object';

export default class ApplicationRoute extends Route {
	@tracked foo = 'foo';

  get bar() {
    return `${this.foo} bar`;
  }

gossi

import Modifier from 'ember-modifier';
import { action } from '@ember/object';

interface InvokeArgs {
  positional: [() => void],
  named: {}
}

/**
 * Invoke modifier:

gossi

In response to: https://gos.si/blog/ember-2019-reduce-complexity/

The idea in short

1. Keep routing as-is
2. Delete Route and Controller
3. Replace with Page
4. Page extends a glimmer component with special sauce to handle transitions and (query) params

Imagine the following layout (yeah, I like MU):

gossi

import { CompatibleInputEvent, IS_INPUT_SUPPORTED, normalizeInputEvent } from 'event-support';

// assuming `element` is a reference to an <input> elem

element.addEventListener('keydown', (event: KeyboardEvent) => {
  const e = normalizeInputEvent(event);

  if (!IS_INPUT_SUPPORTED || event.key.length > 1) {
    handleEvent(e);
  }

gossi

export const normalizeInputEvent = function(event: KeyboardEvent | InputEvent): CompatibleInputEvent {
  const e: CompatibleInputEvent = {
    originalEvent: event
  };

  if (event instanceof KeyboardEvent) {
    if (event.key === 'Backspace') {
      e.inputType = 'deleteContentBackward';
      e.navigationType = 'cursorLeft';
    } else if (event.key === 'Delete') {

gossi

/**
 * A normalized event from InputEvent and KeyboardEvent that works from ie11
 * over modern browsers to android browsers (because that beast is worse than ie6)
 */
export interface CompatibleInputEvent {
  data?: string;
  inputType?: string;
  navigationType?: string;
  originalEvent: KeyboardEvent | InputEvent;
}

gossi

// Reference for InputEvent: https://w3c.github.io/input-events/#interface-InputEvent
export const IS_INPUT_SUPPORTED = (function() {
  try {
    // just kill browsers off, that throw an error if they don't know
    // `InputEvent`
    const event = new InputEvent('input', {
      data: 'xyz',
      inputType: 'deleteContentForward'
    });
    let support = false;

gossi

Ember Components Element API

Background

I don't know what happens to be there first: Ember Components or Web Components. Actually doesn't matter because markup wise they are pretty identical. You can create a custom element to be used in your HTML markup, next to existing HTML elements. The components itself have to follow a specific naming scheme to distinguish them from regular HTML elements. They should either be written in <kebap-case> or <StudlyCase>. There is also a special syntax for attributes and arguments of ember and glimmer components (arguments are passed with the @ sigil). These are the visually distinction from components to regular HTML elements. From just watching at the markup it is possible to identify regular HTML elements and components, though it is not possible to say whether it is a webcomponent, an ember component or a glimmer component, e.g. <video-player id='abc'> could be either of that.

Over the past years, the DDAU pattern has been established as a data flow to pas