- Documentation: https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events
- Use case: broadcasting data from server to browsers
- Benefits:
- Easy to understand and implement (only a few lines of code)
- No library is needed
- Can use same HTTP(S) authentication as elsewhere in the app (which can’t be done with websockets)
import invariant from "tiny-invariant"; | |
class AmalgoBox extends HTMLElement { | |
get input() { | |
return this.querySelector("input") as HTMLInputElement; | |
} | |
get button() { | |
return this.querySelector("button") as HTMLButtonElement; | |
} |
export type Tuple2<A, B> = [A, B]; | |
export type Tuple3<A, B, C> = [A, B, C]; | |
export type Tuple4<A, B, C, D> = [A, B, C, D]; | |
export type Tuple5<A, B, C, D, E> = [A, B, C, D, E]; | |
export type Tuple6<A, B, C, D, E, F> = [A, B, C, D, E, F]; | |
export type Tuple7<A, B, C, D, E, F, G> = [A, B, C, D, E, F, G]; | |
export type Tuple8<A, B, C, D, E, F, G, H> = [A, B, C, D, E, F, G, H]; | |
export type Tuple9<A, B, C, D, E, F, G, H, I> = [A, B, C, D, E, F, G, H, I]; | |
export type Tuple10<A, B, C, D, E, F, G, H, I, J> = [A, B, C, D, E, F, G, H, I, J]; |
const handler = { | |
get(target, propKey, receiver) { | |
if (/^_[0-9]+$/.test(propKey)) { | |
const result = []; | |
const first = Number(receiver); | |
const last = Number(propKey.slice(1)); | |
for (let i=first; i<=last; i++) { | |
result.push(i); | |
} | |
return result; |
This content moved here: https://exploringjs.com/impatient-js/ch_arrays.html#quickref-arrays
// Example Usage: | |
eventually(20)(() => fetch('http://i.fail.often.com/data.json')) | |
.then(data => console.log(data)) | |
.catch(e => console.log(e)); | |
function eventually<T>( | |
giveUpAfterNumberOfRetries: number, | |
nextInterval: (numberOfRetries: number) => number = linearRetryInterval | |
) { |
// precondition: xs is always an array | |
function head(xs) { | |
if (xs.length === 0) return null | |
return xs[0] | |
} | |
function tail(xs) { | |
return xs.slice(1) | |
} |
#!/bin/sh | |
BOLD=$(tput BOLD) | |
NORMAL=$(tput sgr0) | |
RED='\033[0;31m' | |
LOCAL_SETTINGS_BASE=~/Library/Application\ Support/Code | |
LOCAL_SETTINGS="${LOCAL_SETTINGS_BASE}/User" | |
REMOTE_SETTINGS=~/Google\ Drive/App\ Sync/vscode/Settings |
dialog { | |
position: fixed; | |
top: 50%; | |
left: 50%; | |
right: auto; | |
padding: 30px; | |
transform: perspective(500px) translate(-50%, -50%); | |
background: linear-gradient(to bottom, #FFF, #F4F4F4) #FFF; | |
border: none; | |
border-radius: 3px; |
CertSimple just wrote a blog post arguing ES2017's async/await was the best thing to happen with JavaScript. I wholeheartedly agree.
In short, one of the (few?) good things about JavaScript used to be how well it handled asynchronous requests. This was mostly thanks to its Scheme-inherited implementation of functions and closures. That, though, was also one of its worst faults, because it led to the "callback hell", an seemingly unavoidable pattern that made highly asynchronous JS code almost unreadable. Many solutions attempted to solve that, but most failed. Promises almost did it, but failed too. Finally, async/await is here and, combined with Promises, it solves the problem for good. On this post, I'll explain why that is the case and trace a link between promises, async/await, the do-notation and monads.
First, let's illustrate the 3 styles by implementing