Heaven NE-SmallTown

## flexible-ext.js
;(function(win, lib) {
      var doc = win.document;
      var docEl = doc.documentElement;
      var metaEl = doc.querySelector('meta[name="viewport"]');
      var tid;
      var flexible = lib.flexible || (lib.flexible = {});

      var ua = navigator.userAgent;
      var matches = ua.match(/Android[\S\s]+AppleWebkit\/(\d{3})/i);
      var UCversion = ua.match(/U3\/((\d+|\.){5,})/i);

## coordinating-async-react.md

      
              1 file
            
          
              0 forks
            
          
                0 comments
              
            
              0 stars
            
          
                NE-SmallTown
                / coordinating-async-react.md
            
            
              Created
              September 19, 2017 01:23
                — forked from acdlite/coordinating-async-react.md
            
              
                Demo: Coordinating async React with non-React views
              
          
    Demo: Coordinating async React with non-React views

tl;dr I built a demo illustrating what it might look like to add async rendering to Facebook's commenting interface, while ensuring it appears on the screen simultaneous to the server-rendered story.
A key benefit of async rendering is that large updates don't block the main thread; instead, the work is spread out and performed during idle periods using cooperative scheduling.
But once you make something async, you introduce the possibility that things may appear on the screen at separate times. Especially when you're dealing with multiple UI frameworks, as is often the case at Facebook.
How do we solve this with React?

  
## what-forces-layout.md

      
              1 file
            
          
              0 forks
            
          
                0 comments
              
            
              0 stars
            
          
                NE-SmallTown
                / what-forces-layout.md
            
            
              Created
              September 26, 2017 03:25
                — forked from paulirish/what-forces-layout.md
            
              
                What forces layout/reflow. The comprehensive list.
              
          
    What forces layout / reflow

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.
Element

Box metrics


elem.offsetLeft, elem.offsetTop, elem.offsetWidth, elem.offsetHeight, elem.offsetParent
elem.clientLeft, elem.clientTop, elem.clientWidth, elem.clientHeight
elem.getClientRects(), elem.getBoundingClientRect()


## jsx_explicit_do_generator_cases.md

      
              1 file
            
          
              0 forks
            
          
                0 comments
              
            
              0 stars
            
          
                NE-SmallTown
                / jsx_explicit_do_generator_cases.md
            
            
              Created
              November 19, 2017 04:47
                — forked from clemmy/jsx_explicit_gexp_cases.md
            
          
    *{{ a: 1 }} // { a: 1 }

*{
  ({ a: 1 })
} // { a: 1 }


## Article.md

      
              5 files
            
          
              0 forks
            
          
                0 comments
              
            
              0 stars
            
          
                NE-SmallTown
                / Article.md
            
            
              Created
              January 7, 2018 12:58
                — forked from Warry/Article.md
            
              
                How to make faster scroll effects?
              
          
    How to make faster scroll effects?


Avoid too many reflows (the browser to recalculate everything)
Use advanced CSS3 for graphic card rendering
Precalculate sizes and positions

Beware of reflows

The reflow appens as many times as there are frames per seconds. It recalculate all positions that change in order to diplay them. Basically, when you scroll you execute a function where you move things between two reflows. But there are functions that triggers reflows such as jQuery offset, scroll... So there are two things to take care about when you dynamically change objects in javascript to avoid too many reflows:

  
## promise-monad-proof.js
//-------------------------------------------------------------
//
// Hypothesis:
//
// Promises/A is a Monad
//
// To be a Monad, it must provide at least:
// - A unit (aka return or mreturn) operation that creates a corresponding
//   monadic value from a non-monadic value.
// - A bind operation that applies a function to a monadic value

## user-timing-rum.js
// Support routines for automatically reporting user timing for common analytics platforms
// Currently supports Google Analytics, Boomerang and SOASTA mPulse
// In the case of boomerang, you will need to map the event names you want reported
// to timer names (for mPulse these need to be custom0, custom1, etc) using a global variable:
// rumMapping = {'aft': 'custom0'};
(function() {
var wtt = function(n, t, b) {
  t = Math.round(t);
  if (t >= 0 && t < 3600000) {
    // Google Analytics

## firefoxBackgroundBug.html
<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8" />
    <title>Test case for bug in Firefox where a background image in a SVG isn't rendered to the canvas unless a workaround is applied</title>
</head>
<body>
    <canvas id="canvas" style="border:1px solid black;" width="200" height="200"></canvas>
    <script type="text/javascript">
        var canvas = document.getElementById("canvas"),

## apache-preconnect-workaround-README
script to kill apache 1.3 / 2.x prefork httpd processes serving preconnect connections, in an attempt to prevent chrome from causing a DoS against the httpd

This is version 2 of https://gist.github.com/eqhmcow/4774549

The major change is the use of two processes instead of one:

One process makes server-status requests, the other kills idle prefork processes.

This allows the kill script to continue killing idle processes even when Chrome has effectively DoS'd the apache server. When this happens, the check script can't get an updated status response back immediately, but the kill script can hopefully free up a slot by killing some processes. Having an uninterrupted request in the socket queue allows us to get an updated response after killing the Chrome preconnections are killed.

## bookmarklet
javascript:(function(){if(window._activeElInterval){clearInterval(window._activeElInterval);delete window._activeElInterval;}else{var activeEl;window._activeElInterval=setInterval(function(){var currentActiveEl=document.activeElement;if(currentActiveEl!==activeEl){activeEl=currentActiveEl;console.log(activeEl);}},200);}})();
	;(function(win, lib) {
	var doc = win.document;
	var docEl = doc.documentElement;
	var metaEl = doc.querySelector('meta[name="viewport"]');
	var tid;
	var flexible = lib.flexible \|\| (lib.flexible = {});

	var ua = navigator.userAgent;
	var matches = ua.match(/Android[\S\s]+AppleWebkit\/(\d{3})/i);
	var UCversion = ua.match(/U3\/((\d+\|\.){5,})/i);
	//-------------------------------------------------------------
	//
	// Hypothesis:
	//
	// Promises/A is a Monad
	//
	// To be a Monad, it must provide at least:
	// - A unit (aka return or mreturn) operation that creates a corresponding
	// monadic value from a non-monadic value.
	// - A bind operation that applies a function to a monadic value
	// Support routines for automatically reporting user timing for common analytics platforms
	// Currently supports Google Analytics, Boomerang and SOASTA mPulse
	// In the case of boomerang, you will need to map the event names you want reported
	// to timer names (for mPulse these need to be custom0, custom1, etc) using a global variable:
	// rumMapping = {'aft': 'custom0'};
	(function() {
	var wtt = function(n, t, b) {
	t = Math.round(t);
	if (t >= 0 && t < 3600000) {
	// Google Analytics
	<!DOCTYPE html>
	<html>
	<head>
	<meta charset="utf-8" />
	<title>Test case for bug in Firefox where a background image in a SVG isn't rendered to the canvas unless a workaround is applied</title>
	</head>
	<body>
	<canvas id="canvas" style="border:1px solid black;" width="200" height="200"></canvas>
	<script type="text/javascript">
	var canvas = document.getElementById("canvas"),
	script to kill apache 1.3 / 2.x prefork httpd processes serving preconnect connections, in an attempt to prevent chrome from causing a DoS against the httpd

	This is version 2 of https://gist.github.com/eqhmcow/4774549

	The major change is the use of two processes instead of one:

	One process makes server-status requests, the other kills idle prefork processes.

	This allows the kill script to continue killing idle processes even when Chrome has effectively DoS'd the apache server. When this happens, the check script can't get an updated status response back immediately, but the kill script can hopefully free up a slot by killing some processes. Having an uninterrupted request in the socket queue allows us to get an updated response after killing the Chrome preconnections are killed.