mrvicadai

Exploring Entity Component Systems

In Elm Entity-Component-System (or ECS) is a pattern for designing programs that is prevalent in the games industry. This pattern consists of three simple parts:

• Entity : A uniquely identifiable object that may contain any number of components
• Component : A property usually representing the raw data of one aspect of the object. (Position is a component, Velocity is a component, Strength is a component, etc...)
• System : A continuous process performing actions on every entity that possesses a component of the same aspect as that system

To understand this, let us try to make a simple example: Boxes that move in space:

mrvicadai

/**
 * Generates a client ID in the format historically used by the Google Analytics
 * JavaScript libraries. Note that any alphanumeric value may be used, but
 * ideally each should be unique to a given client.
 *
 * More information on Client IDs:
 * https://developers.google.com/analytics/devguides/collection/protocol/v1/email#client-id-cid
 */
function generateGaClientId() {

mrvicadai

When receiving JSON data from other resources(server API etc), we need Json.Decode to convert the JSON values into Elm values. This gist let you quickly learn how to do that.

I like to follow working example code so this is how the boilerplate will look like:

import Graphics.Element exposing (Element, show)
import Task exposing (Task, andThen)
import Json.Decode exposing (Decoder, int, string, object3, (:=))

import Http

mrvicadai

module Main exposing (main)

import Html.App
import Html exposing (Html, div, ul, li, form, input, button, strong, text)
import Html.Events exposing (onSubmit, onInput)
import Html.Attributes exposing (type', value)
import Dict exposing (Dict)


-- MODEL

mrvicadai

module FileUtils exposing (..)

import Native.FileUtils
import Html exposing (..)
import Html.Events exposing (..)
import Http exposing (Body)
import Json.Decode as Json


type alias File =

mrvicadai

Architecture in Elm

This document is a collection of concepts and strategies to make large Elm projects modular and extensible.

We will start by thinking about the structure of signals in our program. Broadly speaking, your application state should live in one big foldp. You will probably merge a bunch of input signals into a single stream of updates. This sounds a bit crazy at first, but it is in the same ballpark as Om or Facebook's Flux. There are a couple major benefits to having a centralized home for your application state:

1. There is a single source of truth. Traditional approaches force you to write a decent amount of custom and error prone code to synchronize state between many different stateful components. (The state of this widget needs to be synced with the application state, which needs to be synced with some other widget, etc.) By placing all of your state in one location, you eliminate an entire class of bugs in which two components get into inconsistent states. We also think yo

mrvicadai

<snippet>
    <content><![CDATA[
#${1/./#/g}###
# $1 #
#${1/./#/g}###

$0
      ]]></content>
    <tabTrigger>#</tabTrigger>
    <scope>source.python</scope>

mrvicadai

function run(generator) {
  // Pass in resume for no-wrap function calls
  var iterator = generator(resume);
  var data = null, yielded = false;
  
  next();
  check();
  
  function next(item) {
    var cont = iterator.next(item).value;

mrvicadai

tim@touchsmart:~/Code$ nvm use v0.11.2-generators
Now using node v0.11.2-generators
tim@touchsmart:~/Code$ node --harmony testgen.js 
<Buffer 76 61 72 20 66 73 20 3d 20 72 65 71 75 69 72 65 28 27 66 73 27 29 3b 0a 66 75 6e 63 74 69 6f 6e 20 72 65 61 64 46 69 6c 65 28 70 61 74 68 2c 20 65 6e 63 ...>
Sleeping for 2000ms...
Done

mrvicadai

class PubSub {
  constructor() {
    this.handlers = [];
  }

  subscribe(event, handler, context) {
    if (typeof context === 'undefined') {
      context = handler;
    }