JSuder-xx

/**
 * Imagine a Fluent Builder where some subset of the fluent methods are valid to call
 * * after one or more fluent methods have been called
 * * before one or more fluent methods have been called
 * * limited number of times.
 * 
 * There is no way to enforce such constraints in statically typed languages such as C++, C# or Java when using a single builder
 * class/interface. Developers would need to author many interfaces to represent the different shapes and would likely need to 
 * author many versions of the builder itself (proxies with a specific signature delegating to an underlying source builder). 
 * 

acutmore

A compile-time 4-Bit Virtual Machine implemented in TypeScript's type system. Capable of running a sample 'FizzBuzz' program.

Syntax emits zero JavaScript.

type RESULT = VM<
  [
    ["push", N_1],         // 1
    ["push", False],       // 2
 ["peek", _], // 3

regevbr

'use strict';
// tslint:disable:max-line-length

// based on https://www.reddit.com/r/typescript/comments/aynx0o/safe_deep_property_access_in_typescript

import * as fs from 'fs';

const method = 'getProp';

const TAB = `  `;

swyxio

This is the CFP for my React Rally talk, which was eventually accepted and given here: https://www.youtube.com/watch?v=nyFHR0dDZo0.

If you are a first time speaker, my CFP advice for new speakers is here.

Final Submission: Why React is not Reactive

Functional-reactive libraries like RxJS make it easy to understand how data changes, giving us tools to declaratively handle events and manage state. But while our render methods react to state changes, React isn’t reactive. Instead, we write imperative event-handlers, and trip up on gotchas like async setState and race conditions. Why? In this talk we build a Reactive React to show the difference between the "push" and "pull" paradigms of data flow and understand why React chooses to manage Scheduling as a core Design Principle, enabling awesome features like async rendering and Suspense!

Theme: This talk is a deep dive into React's core design principle around scheduling. Instead of abstr

albertywu

type Methods = 'get' | 'post';

interface Req {
  data: object;
  method: Methods;
  url: string;
  foo?: number
}

class Req implements Req {

JSuder-xx

/** 
 * _Explicitly declare modifications_ to an existing object type via a fluent interface which yields a mapping function 
 * from the original data type to the type derived from the modification commands. 
 * 
 * The value over authoring a simple mapping function directly
 * * harder to make a mistake due to the explicit nature
 * * easier to read.
 * 
 * This is _not_ production quality code but rather a _proof of concept_ gist for applying conditional/mapped
 * types to mapper generation. A real-world usage might involve also generating the type-guard function

emiaj

// Builders

class SimpleBuilder {
    constructor(private current = {}) {

    }

    prop(key: string, value: any) {
        return new SimpleBuilder({ ...this.current, ...{ [key]: value } });
    }

kentcdodds

// tagging strings
const language = 'de'
const user = {
  name: 'Kent C. Dodds',
  birthday: new Date(1988, 9, 18)
}
const translated = translate`
  <div>
    ${'t.hello'} ${user.name}, ${'t.yourBirthdayIs'} ${user.birthday}
  </div>

gaearon

Note:

When this guide is more complete, the plan is to move it into Prepack documentation.
For now I put it out as a gist to gather initial feedback.

A Gentle Introduction to Prepack (Part 1)

If you're building JavaScript apps, you might already be familiar with some tools that compile JavaScript code to equivalent JavaScript code:

• Babel lets you use newer JavaScript language features, and outputs equivalent code that targets older JavaScript engines.

rauschma

This content moved here: https://exploringjs.com/impatient-js/ch_arrays.html#quickref-arrays