Thomas Chen foxnewsnetwork

What is it?

Here is the Ember.js usage pattern for implementing named yield sections using nothing more than if statements and regular yield.

This has the advantage of not introducing irritating extra wrapper elements as is the case when using ember-wormhole or ember-named-yield

The Problem

Starting sometime in Ember 1.13.x, the core team decided that it shall be a bad idea to modify component variables inside the didInsertElement hook in Ember components. The explanation they gave was that it degrades performance (and who knows, perhaps it does, but I never notice because the 1000+ms waits for remote server to return data).

Nevertheless, modifying component properties on didInsertElement is often a necessity when (for example) we need to know the rendered dimensions of an element in order to perform some action:

didInsertElement: ->
  width = @$().width()
  @set "containerWidth", width
 @set "itemWidth", width

Apparently xhr put (and patch) requests from browsers to remote servers ignore the response's Set-Cookie header. I don't know why browsers do this shit, but it's annoying as hell.

Remote Address:127.0.0.1:4000
Request URL:http://localhost:4000/api/sessions
Request Method:POST
Status Code:201 Created
Response Headers
view source
access-control-allow-credentials:true
access-control-allow-origin:http://localhost:4200

The setup

In my Elixir phoenix web app, I have a plug which handles requests made to an internal endpoint which forbids access to all users without a proper authorization in the request header.

Sounds simple right? Well it is, the below is my plug. It checks if the incoming request has a "simwms-master-key" field, and passes all users who have that key.

The Motivation

EmberJS is a full-featured front-end javascript framework for building (as they put it) ambitious apps. Being ambitious, I wanted to build an app that had data models that were queryable like those of SQL, realtime like it was on Websockets, I wanted to do it without building my own customized REST-over-websockets-on-Elixir server stack. Why would I want to do this? Mostly because so many cuts on the server-side reduces devops costs (to 0) and allows me to piggyback on the extremely well-staffed architecture that runs places like Github and Google (so I don't have to ever worry computer-level details like disk IO rate, server RAM, database backup, SSL, geographic distribution, etc.; all of that I would get for free).

TL;DR: so I can build a globally scalable app that I can maintain just by myself (because there is no maintainence)

The Problem

Using Javascript to do heavy client-side data-management means I am either condemned to Calback Hell or (since it's 2015), Promise Monad Hell (y

	import Ember from 'ember';

	export default Ember.Controller.extend({
	appName: 'Ember Twiddle'
	});

	import Ember from 'ember';

	export default Ember.Controller.extend({
	appName: 'Ember Twiddle',
	title: Ember.String.classify('asdf 344 日本語')
	});

	bad_query = from a in Appointment,
	where: is_nil(a.deleted_at),
	order_by: [desc: a.expected_at],
	select: count(a.id)

	good_query = from a in Appointment,
	where: is_nil(a.deleted_at),
	select: count(a.id)

	Repo.one bad_query # throws ** (Postgrex.Error) ERROR (grouping_error): column "a0.expected_at" must appear in the GROUP BY clause or be used in an aggregate function

	import Ember from 'ember';

	export default Ember.Component.extend({
	});