rauschma

Testing TypeScript examples

Challenges:

• Testing expected static errors. In JavaScript, expected dynamic errors can be tested via:
  • assert.throws(() => eval('const myVar;'), SyntaxError);
  • assert.throws(() => null.someProp, TypeError);
• Testing expected inferred types.

Approach:

samthor

import fs from 'fs';

// as per https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/CSSModules/v1Explainer.md
export default function cssModules() {
  return {
    name: 'css-modules',

    async load(id) {
      if (!id.endsWith('.css')) {
        return;

ebidel

<!-- 
Complete feature detection for ES modules. Covers:

1. Static import: import * from './foo.js';
2. Dynamic import(): import('./foo.js').then(module => {...});

Demo: http://jsbin.com/tilisaledu/1/edit?html,output

Thanks to @_gsathya, @kevincennis, @rauschma, @malyw for the help.
-->

dherman

20:54	dherman	1. I imagine an object can only be a global object for one realm, right?
20:54	shu	oh my word yes
20:54	dherman	lol
20:54	dherman	don't panic
20:54	dherman	I'm just collecting invariants
20:54	dherman	(this is for the Realm API)
20:54	dherman	2. if you had a pre-existing object,
20:54	dherman	that isn't a global object
20:55	dherman	would it be problematic to allow using that object as a global object for a new realm?
20:55	shu	yes, the thing that's actually branded GlobalObjects internally can't be just any plain object

dherman

import {b} from "./b.js";
import $ from "jquery";

export function a() {
  // ...
}

ljharb

Array Iteration

https://gist.github.com/ljharb/58faf1cfcb4e6808f74aae4ef7944cff

While attempting to explain JavaScript's reduce method on arrays, conceptually, I came up with the following - hopefully it's helpful; happy to tweak it if anyone has suggestions.

Intro

JavaScript Arrays have lots of built in methods on their prototype. Some of them mutate - ie, they change the underlying array in-place. Luckily, most of them do not - they instead return an entirely distinct array. Since arrays are conceptually a contiguous list of items, it helps code clarity and maintainability a lot to be able to operate on them in a "functional" way. (I'll also insist on referring to an array as a "list" - although in some languages, List is a native data type, in JS and this post, I'm referring to the concept. Everywhere I use the word "list" you can assume I'm talking about a JS Array) This means, to perform a single operation on the list as a whole ("atomically"), and to return a new list - thus making it mu

nzakas

// target is the backing object
let target = { length: 0 },
    proxy = new Proxy(target, {
        set(trapTarget, key, value) {

            let numericKey = Number(key),
                keyIsInteger = Number.isInteger(numericKey);

            // special case for length property - only need to worry if length is
            // shorter than number of array items

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)
    );
  }
}

mhevery

Zone Motivation

Make writing asynchronous code easier by having a consistent way of propagating "context" across related asynchronous operations. Have the "context" be responsible for async-local-storage, allowing the execution before and after hooks, and "context"-local error handling. Finally make sure that the "context"s are composable.

This feature needs to be part of the platform so that library and framework authors can relay on a common well know API, otherwise adoption will be limited.

rauschma

Cheat sheet for callable entities in ES6

Value:

	FD	FE	AF	C	M
Function-callable	✓	✓	✓	×	✓
Constructor-callable	✓	✓	×	✓	×
Prototype	F.p	F.p	F.p	SC	F.p
Property prototype	✓	✓	×	✓	×