Kulshekhar Kabra kulshekhar

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.

Why I'm tired of using and teaching flux

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:

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.

Conceptual Model

At the moment GraphQL allows 2 types of queries:

query
mutation

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

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

Adding PIXEL/GUI to Raspbian Lite

These 'notes' were primarily intended for my own consumption but since there have been surprisingly many comments to it over the years I wanted to do some updates and clarifications. Thanks for all comments.

These instructions will require you to have connection to internet from your pi, WiFi, Ethernet or by some other means like a 3G USB dongle or something.

Preparations

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?

Unicode Character Look-Alikes

Original Letter	Look-Alike(s)
a	а ạ ą ä à á ą
c	с ƈ ċ
d	ԁ ɗ
e	е ẹ ė é è
g	ġ
h	һ

	'use strict';

	const types = {
	[Number ] : 'number',
	[String ] : 'string',
	[Boolean] : 'boolean',
	[Object ] : 'object'
	};

	function of(...typesToCheck) {

	/*
	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

	package main

	import (
	"crypto/rand"
	"encoding/base64"
	"fmt"
	"io"
	"math/big"
	)