Skip to content

Instantly share code, notes, and snippets.

View loklaan's full-sized avatar
🐛
"You find the weirdest bugs 🎖" – Other Engineers

Lochlan Bunn loklaan

🐛
"You find the weirdest bugs 🎖" – Other Engineers
View GitHub Profile
@skevy
skevy / gist:8a4ffc3cfdaf5fd68739
Last active February 4, 2017 04:59
Redux with reduced boilerplate

Note

I would recommend @acdlite's redux-actions over the methods suggested in this Gist.

The methods below can break hot-reloading and don't support Promise-based actions.

Even though 'redux-actions' still uses constants, I've come to terms with the fact that constants can be good, especially in bigger projects. You can reduce boilerplate in different places, as described in the redux docs here: http://gaearon.github.io/redux/docs/recipes/ReducingBoilerplate.html


#/usr/bin/env bash
git config --global init.templatedir '~/.git-templates' && \
mkdir -p ~/.git-templates/hooks && \
cd ~/.git-templates/hooks
cat >post-checkout <<'EOL'
changed_files="$(git diff-tree -r --name-only --no-commit-id ORIG_HEAD HEAD)"
check_run() {
@aldendaniels
aldendaniels / alternative-to-higher-order-components.md
Last active October 6, 2018 09:50
Alternative to Higher-order Components

React now supports the use of ES6 classes as an alternative to React.createClass().

React's concept of Mixins, however, doesn't have a corollary when using ES6 classes. This left the community without an established pattern for code that both handles cross-cutting concerns and requires access to Component Life Cycle Methods.

In this gist, @sebmarkbage proposed an alternative pattern to React mixins: decorate components with a wrapping "higher order" component that handles whatever lifecycle methods it needs to and then invokes the wrapped component in its render() method, passing through props.

While a viable solution, this has a few drawbacks:

  1. There's no way for the child component to override functionality defined on the higher order component.

Parens And Performance

Years ago, some smart folks that worked on JS engines realized that not all JS that's loaded into a page/app initially is needed right away. They implemented JIT to optimize this situation.

JIT means Just-In-Time, which means essentially that the engine can defer processing (parsing, compiling) certain parts of a JS program until a later time, for example when the function in question is actually needed. This deferral means the engine is freer to spend the important cycles right now on the code that's going to run right now. This is a really good thing for JS performance.

Some time later, some JS engine devs realized that they needed to get some hints from the code as to which functions would run right away, and which ones wouldn't. In technical speak, these hints are called heuristics.

So they realized that one very common pattern for knowing that a function was going to run right away is if the first character before the function keyword was a (, because that usually m

@afeld
afeld / gist:4952991
Last active February 8, 2022 03:13
good APIs for mashups

This list has been superseded by Public APIs. Check there for APIs with Auth: No, HTTPS and CORS Yes.


List of data APIs that require no server-side auth or private credentials, and are thus good for small browser-only JS projects.

@lambdahands
lambdahands / _readme.md
Created September 28, 2015 17:09
FlowType and CSS Modules

Huh?

So basically FlowType doesn't know about CSS Modules, a really handy way of dealing with the plagues of CSS in codebases (global variables and dependency wackiness mainly).

What WebPack allows us to do is "require" CSS files and use their class names:

import styles from "my_styles.css";
import React from "react";
@mjackson
mjackson / app.js
Created December 29, 2015 05:07
Using webpack with pixi.js
var PIXI = require('pixi.js')
console.log(PIXI)
@nolanlawson
nolanlawson / parens-and-perf-counterpost.md
Last active August 14, 2023 20:08
"Parens and Performance" – counterpost

"Parens and Performance" – counterpost

Kyle Simpson (@getify) wrote a very thoughtful post decrying optimize-js, which is a tool I wrote that exploits known optimizations in JavaScript engines to make JS bundles parse faster (especially minified bundles, due to what could be reasonably described as a bug in Uglify).

Kyle lays out a good case, but I tend to disagree with nearly all his points. So here's my rebuttal.

var str = 'class ಠ_ಠ extends Array {constructor(j = "a", ...c) {const q = (({u: e}) => {return { [`s${c}`]: Symbol(j) };})({});super(j, q, ...c);}}' +
'new Promise((f) => {const a = function* (){return "\u{20BB7}".match(/./u)[0].length === 2 || true;};for (let vre of a()) {' +
'const [uw, as, he, re] = [new Set(), new WeakSet(), new Map(), new WeakMap()];break;}f(new Proxy({}, {get: (han, h) => h in han ? han[h] ' +
': "42".repeat(0o10)}));}).then(bi => new ಠ_ಠ(bi.rd));';
try {
eval(str);
} catch(e) {
alert('Your browser does not support ES6!')
}