Sylvester Aswin sylvesteraswin
This helper waits for requests initiated by the action to finish. It is similar to waitUntil: 'networkidle' option, but is designed to work with any action, like click.
Example usage:
const waitForNetworkSettled = require('./networkSettled');
// Wait for network settled after navigation,
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'; | |
| const crypto = require('crypto'); | |
| const ENCRYPTION_KEY = process.env.ENCRYPTION_KEY; // Must be 256 bits (32 characters) | |
| const IV_LENGTH = 16; // For AES, this is always 16 | |
| function encrypt(text) { | |
| let iv = crypto.randomBytes(IV_LENGTH); | |
| let cipher = crypto.createCipheriv('aes-256-cbc', Buffer.from(ENCRYPTION_KEY), iv); |
All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.
Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.
elem.offsetLeft,elem.offsetTop,elem.offsetWidth,elem.offsetHeight,elem.offsetParent
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
| // === Arrays | |
| var [a, b] = [1, 2]; | |
| console.log(a, b); | |
| //=> 1 2 | |
| // Use from functions, only select from pattern | |
| var foo = () => [1, 2, 3]; |
Useful for when a blocking user experience is needed (in my case, didn't want people unwittingly loosing their place by scrolling while a modal required their attention): $.scrollLock() locks the body in place, preventing scroll until it is unlocked.
// Locks the page if it's currently unlocked
$.scrollLock();
// ...or vice versa
| #!/bin/bash | |
| # Updates all EC2 instances from git | |
| # Author: anton@sothree.com | |
| CODE_LOCATION=/var/www/your_project | |
| SERVER_PREFIX=your_project | |
| # exit if something fails | |
| set -e |