(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.
(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.
All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.
Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.
elem.offsetLeft
, elem.offsetTop
, elem.offsetWidth
, elem.offsetHeight
, elem.offsetParent
var http = require("http"), | |
url = require("url"), | |
path = require("path"), | |
fs = require("fs") | |
port = process.argv[2] || 8888; | |
http.createServer(function(request, response) { | |
var uri = url.parse(request.url).pathname | |
, filename = path.join(process.cwd(), uri); |
The standard way of understanding the HTTP protocol is via the request reply pattern. Each HTTP transaction consists of a finitely bounded HTTP request and a finitely bounded HTTP response.
However it's also possible for both parts of an HTTP 1.1 transaction to stream their possibly infinitely bounded data. The advantages is that the sender can send data that is beyond the sender's memory limit, and the receiver can act on
All libraries have subtle rules that you have to follow for them to work well. Often these are implied and undocumented rules that you have to learn as you go. This is an attempt to document the rules of React renders. Ideally a type system could enforce it.
A number of methods in React are assumed to be "pure".
On classes that's the constructor, getDerivedStateFromProps, shouldComponentUpdate and render.
This is now an actual repo:
Hi Nicholas,
I saw you tweet about JSX yesterday. It seemed like the discussion devolved pretty quickly but I wanted to share our experience over the last year. I understand your concerns. I've made similar remarks about JSX. When we started using it Planning Center, I led the charge to write React without it. I don't imagine I'd have much to say that you haven't considered but, if it's helpful, here's a pattern that changed my opinion:
The idea that "React is the V in MVC" is disingenuous. It's a good pitch but, for many of us, it feels like in invitation to repeat our history of coupled views. In practice, React is the V and the C. Dan Abramov describes the division as Smart and Dumb Components. At our office, we call them stateless and container components (view-controllers if we're Flux). The idea is pretty simple: components can't
// UPDATE: In 2023, you should probably stop using this! The narrow version of Safari that | |
// does not support `nomodule` is probably not being used anywhere. The code below is left | |
// for posterity. | |
/** | |
* Safari 10.1 supports modules, but does not support the `nomodule` attribute - it will | |
* load <script nomodule> anyway. This snippet solve this problem, but only for script | |
* tags that load external code, e.g.: <script nomodule src="nomodule.js"></script> | |
* | |
* Again: this will **not** prevent inline script, e.g.: |
// 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!"); |