getify

class Foo {
   constructor(x) { this.foo = x; }
   hello() { console.log(this.foo); }
}

class Bar extends Foo {
  constructor(x) { super(x); this.bar = x * 100; }
  world() { console.log(this.bar); }
}

urugator

const React = require('react');

const __DEV__ = process.env.NODE_ENV !== 'production';
const HOOK_NAME = 'useDerivedState';
const NO_DEPS_HINT = 'If there are no dependencies, use "const [state] = useState(fn)"'

/**
 * Copied from from React sources and adjusted
 * inlined Object.is polyfill to avoid requiring consumers ship their own
 * https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/is 

lostintangent

1: Intro

Welcome to the interactive tutorial on how to use side-effect "operators" in MobX! Over the course of the next three samples, you'll learn (and be able to explore) exactly how autorun, when and reaction work, and when/why you would use them when building reactive applications.

littledan

Decorators: yet another proposal

Introduction

Decorators are a proposal for extending JavaScript classes which is widely adopted among developers in transpiler environments, with broad interest in standardization. TC39 has been iterating on decorators proposals for over five years. This document describes a new proposal for decorators based on elements from all past proposals.

Decorators @decorator are functions called on class elements or other JavaScript syntax forms during definition, potentially wrapping or replacing them with a new value returned by the decorator.

A decorated class field is treated as wrapping a getter/setter pair for accessing that storage. Decorated storage is useful for observation/tracking, which has been a pain point for the original legacy/experimental decorators combined with [[Define]] semantics for class fields. These semantics are based on Michel Weststrate's "trapping decorators" proposal.