terminal:
npm i --save-dev rollup rollup-watch rollup-plugin-typescript typescript typings
npm i -S react react-dom
./node_modules/.bin/typings install react react-dom --save
mkdir src dist
touch src/index.tsx| package main | |
| import ( | |
| "crypto/rand" | |
| "encoding/base64" | |
| "fmt" | |
| "io" | |
| "math/big" | |
| ) |
terminal:
npm i --save-dev rollup rollup-watch rollup-plugin-typescript typescript typings
npm i -S react react-dom
./node_modules/.bin/typings install react react-dom --save
mkdir src dist
touch src/index.tsx| /* | |
| sample usage: | |
| var path = getDomPath(element); | |
| console.log(path.join(' > ')); | |
| output: | |
| body > section:eq(0) > div:eq(3) > section#content > section#firehose > div#firehoselist > article#firehose-46813651 > header > h2 > span#title-46813651 | |
| taken from: | |
| http://stackoverflow.com/questions/5728558/get-the-dom-path-of-the-clicked-a |
In this gist I would like to describe an idea for GraphQL subscriptions. It was inspired by conversations about subscriptions in the GraphQL slack channel and different GH issues, like #89 and #411.
At the moment GraphQL allows 2 types of queries:
querymutationReference implementation also adds the third type: subscription. It does not have any semantics yet, so here I would like to propose one possible semantics interpretation and the reasoning behind it.
| 'use strict'; | |
| const types = { | |
| [Number ] : 'number', | |
| [String ] : 'string', | |
| [Boolean] : 'boolean', | |
| [Object ] : 'object' | |
| }; | |
| function of(...typesToCheck) { |
Reposted from Qiita
For almost a year now, I've been using this "flux" architecture to organize my React applications and to work on other people's projects, and its popularity has grown quite a lot, to the point where it shows up on job listings for React and a lot of people get confused about what it is.
There are a billion explainations on the internet, so I'll skip explaining the parts. Instead, let's cut to the chase -- the main parts I hate about flux are the Dispatcher and the Store's own updating mechanism.
If you use a setup similar to the examples in facebook/flux, and you use flux.Dispatcher, you probably have this kind of flow:
| { | |
| "version": "0.1.0", | |
| "command": "go", | |
| "args": ["build"], | |
| "isShellCommand": true, | |
| "showOutput": "silent", | |
| "problemMatcher": { | |
| "owner": "go", |
A checklist for designing and developing internet scale services, inspired by James Hamilton's 2007 paper "On Desgining and Deploying Internet-Scale Services."
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.