Ctrl+h select file tree
Ctrl+l select file editor
Shift+h left editor tab
Shift+l right editor tab
Alt+j move current line up
Alt+k move current line down
double space filename search(telescope) - `Ctrl+d` and `Ctrl+u` to scroll preview
// abstract class, not intended to be instantiated directly | |
class CalendarItem { | |
static #UNSET = Symbol("unset") | |
static #isUnset(v) { | |
return v === this.#UNSET; | |
} | |
static { | |
for (let [idx,msg] of [ | |
"ID is already set.", | |
"ID is unset.", |
I am often asked why I don't like a tool like TS (or Flow), and by implication, if I don't like it, the assumption is that I don't want any type aware tooling. That's not true, though.
I have many ideas for what I think type-aware tooling in JS could/should be, and they just happen to diverge significantly enough from TS/Flow that I can't bend into pretzels to fit into that mold.
Instead, I've worked on designing a tool I call TypL that I think addresses my concerns. It's in progress.
Here's my main list of motivations for designing TypL instead of TS/Flow:
- I want a system that has both compile-time checking AND run-time checking. TypL's design is to compile away the stuff that it checks at compile time and can verify, and leave in the stuff that it knows needs run-time checking. That way, you don't have to write different sorts of type checking for compile-time and run-time. You get both from one set of typing annotation. It doesn't really seem tha
import csv | |
import gzip | |
import io | |
import json | |
from urllib.parse import urlencode, urljoin | |
from urllib.request import Request, urlopen | |
class BrasilIO: |
const inBrowser = typeof window !== 'undefined' | |
const inWeex = typeof WXEnvironment !== 'undefined' && !!WXEnvironment.platform | |
const weexPlatform = inWeex && WXEnvironment.platform.toLowerCase() | |
const UA = inBrowser && window.navigator.userAgent.toLowerCase() | |
const isIE = UA && /msie|trident/.test(UA) | |
const isIE9 = UA && UA.indexOf('msie 9.0') > 0 | |
const isEdge = UA && UA.indexOf('edge/') > 0 | |
const isAndroid = (UA && UA.indexOf('android') > 0) || (weexPlatform === 'android') | |
const isIOS = (UA && /iphone|ipad|ipod|ios/.test(UA)) || (weexPlatform === 'ios') | |
const isChrome = UA && /chrome\/\d+/.test(UA) && !isEdge |
var square = {} | |
(function() { | |
var length = 0, width = 0 | |
Object.defineProperty(square, "length", { | |
get: function() { return length }, | |
set: function(value) { length = width = value } | |
}) |
Thanks to React hooks you have now happily turned all your classes into functional components.
Wait, all your components? Not quite. There is one thing that can still only be implemented using classes: Error boundaries.
There is just no functional equivalent for componentDidCatch
and deriveStateFromError
yet.
if (!Object.is) { | |
Object.is = function(x, y) { | |
// SameValue algorithm | |
if (x === y) { // Steps 1-5, 7-10 | |
// Steps 6.b-6.e: +0 != -0 | |
return x !== 0 || 1 / x === 1 / y; | |
} else { | |
// Step 6.a: NaN == NaN | |
return x !== x && y !== y; | |
} |
React recently introduced an experimental profiler API. This page gives instructions on how to use this API in a production release of your app.
Table of Contents
React DOM automatically supports profiling in development mode for v16.5+, but since profiling adds some small additional overhead it is opt-in for production mode. This gist explains how to opt-in.
<!DOCTYPE html> | |
<html> | |
<head> | |
<meta charset="UTF-8" /> | |
<title>Add React in One Minute</title> | |
</head> | |
<body> | |
<h2>Add React in One Minute</h2> | |
<p>This page demonstrates using React with no build tooling.</p> |