anthonybrown

@kangax's ES6 quiz, explained

@kangax created a new interesting quiz, this time devoted to ES6 (aka ES2015). I found this quiz very interesting and quite hard (made myself 3 mistakes on first pass).

Here we go with the explanations:

Question 1:

(function(x, f = () => x) {

anthonybrown

javascript:(function(){if(window._activeElInterval){clearInterval(window._activeElInterval);delete window._activeElInterval;}else{var activeEl;window._activeElInterval=setInterval(function(){var currentActiveEl=document.activeElement;if(currentActiveEl!==activeEl){activeEl=currentActiveEl;console.log(activeEl);}},200);}})();

anthonybrown

import React from 'react';
import _ from 'lodash';

/**
 * Protect a heavyweight setter by caching values locally.
 * Allows functional controlled components with e.g. a redux backing store,
 * without dispatching actions on every keypress.
 * 
 * @param {*} valueProp the value to cache (e.g. a key from mapStateToProps)
 * @param {*} setterProp the heavyweight setter to protect (e.g. a key from mapDispatchToProps)

anthonybrown

import React, { Component } from "react"
import { Machine } from "xstate"
import * as PropTypes from "prop-types"

class FiniteMachine extends Component {
  machine = Machine(this.props.chart)

  state = {
    data: this.props.reducer(undefined, { type: "@init" }),
    machineState: this.machine.getInitialState()

anthonybrown

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

• Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
• Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
• Once documentation has been written, development should commence, and test-driven development is preferred.
• Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
• When a feature is being modified, it should be modified documentation-first.
• When documentation is modified, so should be the tests.

anthonybrown

import Ember from 'ember';
import Changeset from '../lib/changeset';
import validatePresence from '../validators/presence';

let model = { foo: 'bar' };
let validations = {
	foo: validatePresence()
};
let changeset = new Changeset(model, { validations });

anthonybrown

State Management Patterns

Repositories

Download the following repositories and run yarn install in each:

• Basic Counter
• Pizza Calculator
• Jetsetter
• Offices and Dragons

anthonybrown

{
  "window.zoomLevel": 0,
  "editor.tabSize": 2,
  "editor.renderWhitespace": "all",
  "editor.minimap.enabled": false,
  "editor.fontFamily": "Operator Mono,'Fira Code'",
  "editor.fontLigatures": true,
  "editor.multiCursorModifier": "ctrlCmd",
  "editor.formatOnSave": true,
  "editor.formatOnPaste": true,

anthonybrown

import { h, Component } from 'preact';


/** Creates a new store, which is a tiny evented state container.
 *  @example
 *    let store = createStore();
 *    store.subscribe( state => console.log(state) );
 *    store.setState({ a: 'b' });   // logs { a: 'b' }
 *    store.setState({ c: 'd' });   // logs { c: 'd' }
 */

anthonybrown

JavaScript Slam Poetry