Remove package's dependencies (does not remove package):
brew deps [FORMULA] | xargs brew remove --ignore-dependencies
Remove package:
Observable.prototype[Symbol.asyncIterator] = async function*() { | |
function promiseCapability() { | |
x = {}; | |
x.promise = new Promise((a, b) => { | |
x.resolve = a; | |
x.reject = b; | |
}); | |
return x; | |
} |
/* | |
* common react, redux staff here | |
*/ | |
import {Router, createRoutes} from 'react-router'; | |
import createBrowserHistory from 'history/lib/createBrowserHistory'; | |
import rawRoutes from './routes'; | |
import store from './store'; | |
function mixStoreToRoutes(routes) { | |
return routes && routes.map(route => ({ |
This is a strawman proposal for adding pattern matching to ECMAScript. Pattern matching is useful for matching a value to some structure in a similar way to destructuring. The primary difference between destructuring and pattern matching are the use cases involved - destructuring is useful for binding pieces out of larger structures whereas pattern matching is useful for mapping a value's structure to data or a set of behaviors. In practice this means that destructuring tends to allow many shapes of data and will do its best to bind something out of it, whereas pattern matching will tend to be more conservative.
Additionally, the power of pattern matching is increased substantially when values are allowed to participate in the pattern matching semantics as a matcher as well as a matchee. This proposal includes the notion of a pattern matching protocol - a symbol method that can be implemented by objects that enables developers to use those values in pattern matching. A common scenario w
[Flow][] static type checker is a wonderful attempt to bring [algebric data types][] to JS. It is still fairly new project and there for has few WTFs that can pull you down the rabbit hole. This document is attempt to document things that may seem like a WTF from the perspective of JS developer who tries to employ static type checker, or in other words, some items on the list may be very subjective & based on the background of the writer.
It is very likely that one will wind up using [Polymorphic functions][] to solve a more general problem. And if you define type alias for such a function you may be puzzled what is the right syntax should be used for such type definition.
Let's start with:
To switch easily between Node versions on Debian, instead of tools like [nvm](https://github.com/creationix/nvm), you can just use [Debian's native alternatives system](http://www.debian-administration.org/article/91/Using_the_Debian_alternatives_system). | |
(the following commands require root privilege) | |
- download and install the node executables under /usr/local/bin/nodes/… | |
- add this binaries to the alternative system: | |
update-alternatives --install /usr/bin/node node /usr/bin/nodejs 100 | |
update-alternatives --install /usr/bin/node node /usr/local/bin/nodes/0.10.38/nodejs 50 | |
- to switch between versions, just call `update-alternatives --config node` | |
/* | |
##Device = Desktops | |
##Screen = 1281px to higher resolution desktops | |
*/ | |
@media (min-width: 1281px) { | |
/* CSS */ | |
// Promise.all is good for executing many promises at once | |
Promise.all([ | |
promise1, | |
promise2 | |
]); | |
// Promise.resolve is good for wrapping synchronous code | |
Promise.resolve().then(function () { | |
if (somethingIsNotRight()) { | |
throw new Error("I will be rejected asynchronously!"); |
…specifically React 0.13 using ES6 class syntax
Originally I was implementing the validator as a context, but then I got stung by parent context vs owner context. I'll likely return to the context model when React's context implementation is more final (looks like they're moving towards parent context over owner context, which I'd prefer).
While this gist has been shared and followed for years, I regret not giving more background. It was originally a gist for the engineering org I was in, not a "general suggestion" for any React app.
Typically I avoid folders altogether. Heck, I even avoid new files. If I can build an app with one 2000 line file I will. New files and folders are a pain.