Johan West mrwest808

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:

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

The introduction to Reactive Programming you've been missing

(by @andrestaltz)

This tutorial as a series of videos

If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.

Interesting part (unmounting & API) is at the end if you're not interested in the rest =).

Stress Tests

This animation proposal is just an attempt. In case it doesn't work out, I've gathered a few examples that can test the power of a future animation system.

Parent is an infinitely spinning ball, and has a child ball that is also spinning. Clicking on the parent causes child to reverse spinning direction. This tests the ability of the animation system to compose animation, not in the sense of applying multiple interpolations to one or more variables passed onto the child (this should be trivial), but in the sense that the parent's constantly updating at the same time as the child, and has to ensure that it passes the animation commands correctly to it. This also tests that we can still intercept these animations (the clicking) and immediately change their configuration instead of queueing them.
Typing letters and let them fly in concurrently. This tests concurrency, coordination of an array of ch

Better local require() paths for Node.js

Problem

When the directory structure of your Node.js application (not library!) has some depth, you end up with a lot of annoying relative paths in your require calls like:

const Article = require('../../../../app/models/article');

Those suck for maintenance and they're ugly.

	var express = require('express');
	var app = express();
	var router = express.Router();
	var hbs = require('hbs');

	app.set('view engine', 'html');
	app.engine('html', hbs.__express);

	app.use(express.json());
	app.use(express.urlencoded());

	SASSC = sass --style compact
	COMPSDIR = resources/assets/components
	SASSDIR = resources/assets/css
	JSDIR = resources/assets/js
	DISTDIR = web/dist
	CSSDIR = $(DISTDIR)/css
	SASSINC = $(SASSDIR) \
	$(COMPSDIR)/asimov/src/scss \
	$(COMPSDIR)/asimov-contests/src/scss \
	$(COMPSDIR)/asimovicons/src/scss