Thomas Gossmann gossi

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

The idea in short

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

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

Ember Single File Component (markdown approach)

A syntax we are widely used to write is markdown, which also has a syntax to write blocks of code. In this variant of a potential SFC thingy, the only allowed "top-level-syntaxes" are code blocks. Based on the language they are assigned script, template or style. Everything other than code blocks is ignored (= comment)

References

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

Ember Font Awesome High-Order Components

The idea behind was to have decorators on top of an icon. The idea is taken from eclipse, where it has a "background" icon and then a decorator for each edge (top left, top right, bottom left, bottom right). To stack up icons, such as user in the background and a plus as bottom right decorator.

Luckily this is possible with FA5, see here: https://jsfiddle.net/8oqL3b5p/276/

Taken this and combine it with ember, I was able to create this API:

	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`;
	}

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

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

	/**
	* Invoke modifier:

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

	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') {

	/**
	* 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;
	}

	// 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;