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.
| 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 |
Interesting part (unmounting & API) is at the end if you're not interested in the rest =).
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
| 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()); |
(by @andrestaltz)
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.
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:
Imagine a chat server persisting the messages, a simplified Slack chat. The domain is designed in the object-orientated style. In order to get realtime updates, we need to transport events emitted on the model constructor ("static" events) and on a model instance ("instance" events).
While it may not be immediately clear, the example is covering few other important LoopBack concepts too:
loopback.token in REST)loopback.context in REST)What is not covered:
CSS and SVG recreation of the new Google material design loading spinner.
A Pen by Fran Pérez on CodePen.
| /** Returns a simple relative time string | |
| * @example | |
| * nicetime(new Date()-1e4) == 'Just now' // within the last minute | |
| * nicetime(Date.now()-1e6) == '16m' // within the last hour | |
| * nicetime(Date.now()-1e7) == '2h' // within the last hour | |
| * nicetime('Dec 31, 2014') == '4d' // within the last 7 days | |
| * nicetime('Dec 25, 2014') == 'Dec 25' // over 7 days ago gives a simple date | |
| * nicetime('July 4, 2014') == 'Jul 4, 2014' // over half a year ago adds the year | |
| */ | |
| function nicetime(text) { |
| . | |
| ├── actions | |
| ├── stores | |
| ├── views | |
| │ ├── Anonymous | |
| │ │ ├── __tests__ | |
| │ │ ├── views | |
| │ │ │ ├── Home | |
| │ │ │ │ ├── __tests__ | |
| │ │ │ │ └── Handler.js |