imjasonh

* {
    font-size: 12pt;
    font-family: monospace;
    font-weight: normal;
    font-style: normal;
    text-decoration: none;
    color: black;
    cursor: default;
}

paulirish

/* bling.js */
window.$ = document.querySelector.bind(document);
window.$$ = document.querySelectorAll.bind(document);
Node.prototype.on = window.on = function(name, fn) { this.addEventListener(name, fn); };
NodeList.prototype.__proto__ = Array.prototype;
NodeList.prototype.on = function(name, fn) { this.forEach((elem) => elem.on(name, fn)); };

ef4

<select onchange={{action (mut vehicle) value="target.value"}}>
  {{#each vehicles key="@item" as |vehicleChoice|}}
    <option value={{vehicleChoice}} selected={{eq vehicle vehicleChoice}}>{{vehicleChoice}}</option>
  {{/each}}
</select>

paulirish

What forces layout / reflow

All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.

Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.

Element APIs

Getting box metrics

• elem.offsetLeft, elem.offsetTop, elem.offsetWidth, elem.offsetHeight, elem.offsetParent

gaearon

function mapValues(obj, fn) {
  return Object.keys(obj).reduce((result, key) => {
    result[key] = fn(obj[key], key);
    return result;
  }, {});
}

function pick(obj, fn) {
  return Object.keys(obj).reduce((result, key) => {
    if (fn(obj[key])) {

davideast

isUser(uid) = auth != null && auth.uid == uid;

type Post {
  uid: String;
  title: String;
  description: String;
  timestamp: Number;
}

type User {

runspired

Ember Named Yields

Current Idea

The current thinking floating around for named yields looks something like this. You can't mix use of named blocks and non-blocked content. Once you use a block helper within a component, everything, including your main yield needs to be within one. If you don't use one, then your yielded content is the main block. This gist is a suggestion I have for how named yields should be implemented and work, and follows the evolution of my thinking on it.

marty-wang

const compose = (...fns) => (...args) => fns.reduceRight((input, fn) => fn.apply(null, [].concat(input)), args)

const combine = (...args) => args.join(" ") 
const shout = (x) => x.toUpperCase()
const emphasize = (x) => `${x}!`
const yell = compose(emphasize, shout, combine)

console.log(yell("hello", "world")); // "HELLO WORLD!"

billybonks

These are my thoughts, on how the translation files should be modeled, take into consideration the following postulates:

• Web applications are modeled around their data.
• Web applications data models have the following states.
  • Saved
  • Deleted
  • Updated
  • Empty
  • Created
  • Loading

nemtsov

module.exports = (file, api, options) => {
  const j = api.jscodeshift;

  const printOptions = options.printOptions || {quote: 'single'};
  const root = j(file.source);
  const requires = {};

  const filterAndTransformRequires = path => {
    const varName = path.value.local.name;
    const scopeNode = path.parentPath.scope.node;