Real unit test (isolation, no children render)
Calls:
- constructor
- render
Express makes it easy to nest routes in your routers. But I always had trouble accessing the request object's .params when you had a long URI with multiple parameters and nested routes.
Let's say you're building routes for a website www.music.com. Music is organized into albums with multiple tracks. Users can click to see a track list. Then they can select a single track and see a sub-page about that specific track.
At our application level, we could first have a Router to handle any requests to our albums.
const express = require('express');| 'use strict'; | |
| module.exports = function CustomError(message, extra) { | |
| Error.captureStackTrace(this, this.constructor); | |
| this.name = this.constructor.name; | |
| this.message = message; | |
| this.extra = extra; | |
| }; | |
| require('util').inherits(module.exports, Error); | 
| xcodebuild -exportArchive -exportFormat ipa -archivePath {PATH}/MyApp.xcarchive -exportPath ~/Desktop/MyApp.ipa | 
Hi Nicholas,
I saw you tweet about JSX yesterday. It seemed like the discussion devolved pretty quickly but I wanted to share our experience over the last year. I understand your concerns. I've made similar remarks about JSX. When we started using it Planning Center, I led the charge to write React without it. I don't imagine I'd have much to say that you haven't considered but, if it's helpful, here's a pattern that changed my opinion:
The idea that "React is the V in MVC" is disingenuous. It's a good pitch but, for many of us, it feels like in invitation to repeat our history of coupled views. In practice, React is the V and the C. Dan Abramov describes the division as Smart and Dumb Components. At our office, we call them stateless and container components (view-controllers if we're Flux). The idea is pretty simple: components can't
| // Promise.all is good for executing many promises at once | |
| Promise.all([ | |
| promise1, | |
| promise2 | |
| ]); | |
| // Promise.resolve is good for wrapping synchronous code | |
| Promise.resolve().then(function () { | |
| if (somethingIsNotRight()) { | |
| throw new Error("I will be rejected asynchronously!"); | 
| 'use strict'; | |
| module.exports = function CustomError(message, extra) { | |
| Error.captureStackTrace(this, this.constructor); | |
| this.name = this.constructor.name; | |
| this.message = message; | |
| this.extra = extra; | |
| }; | |
| require('util').inherits(module.exports, Error); | 
(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.
| /** | |
| * Get a random floating point number between `min` and `max`. | |
| * | |
| * @param {number} min - min number | |
| * @param {number} max - max number | |
| * @return {number} a random floating point number | |
| */ | |
| function getRandomFloat(min, max) { | |
| return Math.random() * (max - min) + min; | |
| } | 
| // set-up a connection between the client and the server | |
| var socket = io.connect(); | |
| // let's assume that the client page, once rendered, knows what room it wants to join | |
| var room = "abc123"; | |
| socket.on('connect', function() { | |
| // Connected, let's sign-up for to receive messages for this room | |
| socket.emit('room', room); | |
| }); |