I hereby claim:
- I am kpdecker on github.
- I am kpdecker (https://keybase.io/kpdecker) on keybase.
- I have a public key ASCmQDlX2nLMCqt7JrZ2cjWLVamXlHyuR9OYXP9X1X4Z4go
To claim this, I am signing this object:
I hereby claim:
To claim this, I am signing this object:
/* eslint-disable react/prop-types, react/no-did-mount-set-state */ | |
import React from 'react'; | |
let initialRender = true; | |
export default class ClientOnly extends React.Component { | |
constructor(props) { | |
super(props); | |
this.state = {initialRender}; | |
} |
/* global document */ | |
import React from 'react'; | |
import ReactDOM from 'react-dom'; | |
import TestUtils from 'react-addons-test-utils'; | |
import shallowUtils from 'react-shallow-testutils'; | |
it.browser = function(name, fn) { | |
if (typeof document !== 'undefined') { | |
it(name, fn); | |
} |
diff --git a/lib/resolver.js b/lib/resolver.js | |
index c4cb078..0bbeec5 100644 | |
--- a/lib/resolver.js | |
+++ b/lib/resolver.js | |
@@ -1,42 +1,15 @@ | |
-// This implementation of the url resolver adds awareness for webpack loaders | |
-/* | |
- | |
-Modified from the stylus implementation: | |
- |
This year marks the first year that we are doing full scale rendering of our SPA application on our mobile.walmart.com Node.js tier, which has provided a number of challenges that are very different from the mostly IO-bound load of our prior #nodebf.
The infrastructure outlined for last year is the same but our Home, Item and a few other pages are prerendered on the server using fruit-loops and hula-hoop to execute an optimized version of our client-side JavaScript and provide a SEO and first-load friendly version of the site.
To support the additional CPU load concerns as peak, which we hope will be unfounded or mitigated by our work, we have also taken a variety of steps to increase cache lifetimes of the pages that are being served in this manner. In order of their impact:
/* exported Handlebars */ | |
(function (root, factory) { | |
if (typeof define === 'function' && define.amd) { | |
define([], factory); | |
} else if (typeof exports === 'object') { | |
module.exports = factory(); | |
} else { | |
root.Handlebars = root.Handlebars || factory(); | |
} | |
}(this, function () { |
Recently had a code review where the distinction between setInterval
and setTimeout
under Node came up. Wanting to answer this question I put together some simple tests. The behavior of the two implementations, as of Node 0.10.30, was surprisingly reverse of my expecations, but there is a lot of nuance to how the event loop works in this case.
setInterval
's behavior is similar to what one would expect from a exec+setTimeout
loop. It's period is going to be it's exec time plus the interval value.
setInterval Delay: 50 Interval: 100 Wait mode: none
Compat Mode
ops/msec handlebars compat dust eco mustache WINNER(S)
---------------------------------------------------------------------------------------------------------------------------------
arguments 473 ±3 (7) 468 ±4 (5) NA NA NA handlebars
array-each 1737 ±10 (5) 867 ±12 (3) 1172 ±7 (6) 306 ±12 (3) 349 ±6 (7) handlebars
array-mustache 1541 ±21 (5) 847 ±8 (4) NA NA NA handlebars
complex 798 ±4 (3) 284 ±2 (4) 625 ±9 (4) 209 ±8 (3) 162 ±1 (6) handlebars
data 687 ±3 (4) 557 ±2 (4) NA NA NA handlebars
depth-1 880 ±10 (5) 885 ±5 (3) NA 312 ±12 (4)
<!DOCTYPE html> | |
<html> | |
<head> | |
</head> | |
<body> | |
<canvas id="output" width="600" height="800"></canvas> | |
<script> | |
// Renderer code | |
var output = document.getElementById('output'), |
// WARN: DO NOT RUN THIS. IT WILL BREAK YOUR SANITY. | |
console.log('Loading a web page'); | |
var page = require('webpage').create(); | |
page.onConsoleMessage = function(msg, lineNum, sourceId) { | |
console.log('CONSOLE: ' + msg + ' (from line #' + lineNum + ' in "' + sourceId + '")'); | |
}; | |
page.evaluateJavaScript('function() {\ | |
window.doIt = function() {\ | |
console.log(setTimeout(doIt, 0));\ |