'use strict';
const ENTER_KEY = 13;
const emailFactory = function ({
React,
setEmail,
/** | |
* Stores are just seed + reduce function. | |
* Notice they are plain objects and don't own the state. | |
*/ | |
const countUpStore = { | |
seed: { | |
counter: 0 | |
}, | |
reduce(state, action) { |
2015-01-29 Unofficial Relay FAQ
Compilation of questions and answers about Relay from React.js Conf.
Disclaimer: I work on Relay at Facebook. Relay is a complex system on which we're iterating aggressively. I'll do my best here to provide accurate, useful answers, but the details are subject to change. I may also be wrong. Feedback and additional questions are welcome.
Relay is a new framework from Facebook that provides data-fetching functionality for React applications. It was announced at React.js Conf (January 2015).
The MIT License (MIT) | |
Copyright (c) 2014 Tomas Kafka | |
Permission is hereby granted, free of charge, to any person obtaining a copy | |
of this software and associated documentation files (the "Software"), to deal | |
in the Software without restriction, including without limitation the rights | |
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell | |
copies of the Software, and to permit persons to whom the Software is | |
furnished to do so, subject to the following conditions: |
/** | |
* @jsx React.DOM | |
*/ | |
var React = require('react'); | |
var TapEventMixin = { | |
Tap_onTouchStart: function(event) { | |
this.hasTouch = true; |
import scala.concurrent.duration._ | |
import scala.concurrent.ExecutionContext | |
import scala.concurrent.Future | |
import akka.pattern.after | |
import akka.actor.Scheduler | |
/** | |
* Given an operation that produces a T, returns a Future containing the result of T, unless an exception is thrown, | |
* in which case the operation will be retried after _delay_ time, if there are more possible retries, which is configured through | |
* the _retries_ parameter. If the operation does not succeed and there is no retries left, the resulting Future will contain the last failure. |
Sooo, CRDTs.
They broadly fall into two groups, Commutative and Convergent.
- Commutative Replicated Data Types (aka CmRDTs): These are also referred to as op-based CRDTs. Essentially, updates cause commutative operations to be broadcast. However, this broadcast channel is required to be reliable and have an order (see §2.2.2 of [1] below).
- Convergent Replicated Data Types (aka CvRDTs):
These are also referred to as state-based CRDTs. Essentially they consist of a data structure with a commutative
merge operation
which will deterministically take two of these structures and merge them into one, preserving updates. These don't require a reliable broadcast system, instead can rely on the liveness properties of an Eventually Consistent (EC) system normally.
Why is the reliable broadcast thing an issue? To have it you require strong consistency. CRDTs are supposed to be designed for Highly Available, EC systems, which by definition (and CAP theorem) can't have strong consistency[+].
Eric Bidelman has documented some of the common workflows possible with headless Chrome over in https://developers.google.com/web/updates/2017/04/headless-chrome.
If you're looking at this in 2016 and beyond, I strongly recommend investigating real headless Chrome: https://chromium.googlesource.com/chromium/src/+/lkgr/headless/README.md
Windows and Mac users might find using Justin Ribeiro's Docker setup useful here while full support for these platforms is being worked out.
<!-- Raven.js Config --> | |
<script src="{{ JS_PATH }}/lib/raven.js" type="text/javascript"></script> | |
<script type="text/javascript"> | |
// Ignore list based off: https://gist.github.com/1878283 | |
var ravenOptions = { | |
// Will cause a deprecation warning, but the demise of `ignoreErrors` is still under discussion. | |
// See: https://github.com/getsentry/raven-js/issues/73 | |
ignoreErrors: [ | |
// Random plugins/extensions | |
'top.GLOBALS', |