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: [email protected] | |
CODE_LOCATION=/var/www/your_project | |
SERVER_PREFIX=your_project | |
# exit if something fails | |
set -e |