sebmarkbage

I heard some points of criticism to how React deals with reactivity and it's focus on "purity". It's interesting because there are really two approaches evolving. There's a mutable + change tracking approach and there's an immutability + referential equality testing approach. It's difficult to mix and match them when you build new features on top. So that's why React has been pushing a bit harder on immutability lately to be able to build on top of it. Both have various tradeoffs but others are doing good research in other areas, so we've decided to focus on this direction and see where it leads us.

I did want to address a few points that I didn't see get enough consideration around the tradeoffs. So here's a small brain dump.

"Compiled output results in smaller apps" - E.g. Svelte apps start smaller but the compiler output is 3-4x larger per component than the equivalent VDOM approach. This is mostly due to the code that is usually shared in the VDOM "VM" needs to be inlined into each component. The tr

joepie91

Not all random values are created equal - for security-related code, you need a specific kind of random value.

A summary of this article, if you don't want to read the entire thing:

• Don't use Math.random(). There are extremely few cases where Math.random() is the right answer. Don't use it, unless you've read this entire article, and determined that it's necessary for your case.
• Don't use crypto.getRandomBytes directly. While it's a CSPRNG, it's easy to bias the result when 'transforming' it, such that the output becomes more predictable.
• If you want to generate random tokens or API keys: Use uuid, specifically the uuid.v4() method. Avoid node-uuid - it's not the same package, and doesn't produce reliably secure random values.
• If you want to generate random numbers in a range: Use random-number-csprng.

You should seriously consider reading the entire article, though - it's

jlongster

const t = require("tcomb");
// imstruct is a tcomb type builder that internally builds an
// Immutable.Record object, but applies tcomb's type system to it
const imstruct = require("../util/imstruct");

const Person = imstruct({
  name: t.String,
  age: t.Number
});

domenic

// Dynamic module loading using runtime-composed strings, decisions, etc.

for (const m of ["cool", "awesome", "fun", "whee"]) {
  if (Math.random() > 0.5) {
    importModule(`/js/${m}.js`).then(
      module => console.log("Module instance object for " + m, module),
      e => console.error(e)
    );
  }
}

ryanflorence

For those of you asking about my "redux mental breakthrough":

I've struggled with how to keep the state of multiple instances of the same component class in redux. I kept thinking that I had an "unkown number" of instances and would need to somehow carve out a piece of state when the new instance was mounted.

I don't know why I was thinking this way. Thinking is hard, isn't it? (I'm in the UK and they often say "isn't it?" after asserting something and I love it, anyway....)

bterlson

Pattern Matching

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

jlongster

A lot of people mentioned other immutable JS libraries after reading my post. I thought it would be good to make a list of available ones.

There are two types of immutable libraries: simple helpers for copying JavaScript objects, and actual persistent data structure implementations. My post generally analyzed the tradeoffs between both kinds of libraries and everything applies to the below libraries in either category.

Libraries are sorted by github popularity.

Persistent Data Structures w/structural sharing

OlegIlyenko

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.

paulirish

What forces layout / reflow

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.

Element APIs

Getting box metrics

• elem.offsetLeft, elem.offsetTop, elem.offsetWidth, elem.offsetHeight, elem.offsetParent

kastermester

var estreeWalker = require('estree-walker');
module.exports = function(ast, mapper){
	estreeWalker.walk(ast, {
		enter: function(node, parent){
			if(node.type !== 'CallExpression'){
				return;
			}
			if(node.callee.type == 'Identifier'){
				if(node.callee.name == 'require' || node.callee.name == 'define'){
					// AMD style require/defines