This content moved here: https://exploringjs.com/impatient-js/ch_arrays.html#quickref-arrays
const path = require('path'); | |
const { STATUS_CODES } = require('http'); | |
exports.rewriteHandler = (evt, ctx, cb) => { | |
const { request } = evt.Records[0].cf; | |
const htmlExtRegex = /(.*)\.html?$/; | |
if (htmlExtRegex.test(request.uri)) { | |
const uri = request.uri.replace(htmlExtRegex, '$1'); | |
return cb(null, redirect(uri)); | |
} |
import axios from 'axios' | |
import fetch from './fetch' | |
export default { | |
async fetchPage ({ dispatch }, { query, headers }, ref) { | |
// every time this action is dispatched, make the request using the fetch helper | |
// which ensures we cancel previous requests and only mutate state after the latest one | |
await fetch(ref, { | |
request: cancelToken => { | |
return Promise.all( |
With the addition of ES modules, there's now no fewer than 24 ways to load your JS code: (inline|not inline) x (defer|no defer) x (async|no async) x (type=text/javascript | type=module | nomodule) -- and each of them is subtly different.
This document is a comparison of various ways the <script>
tags in HTML are processed depending on the attributes set.
If you ever wondered when to use inline <script async type="module">
and when <script nomodule defer src="...">
, you're in the good place!
Note that this article is about <script>
s inserted in the HTML; the behavior of <script>
s inserted at runtime is slightly different - see Deep dive into the murky waters of script loading by Jake Archibald (2013)
The blog post has been written: https://kentcdodds.com/blog/typescript-function-syntaxes
I'm trying to create examples of all the different ways to write functions and function type definitions in TypeScript.
One requirement is these examples must work with strict mode (noImplicitAny
, etc) enabled.
If I'm missing anything, please add comments below with examples. I'll eventually put this into a blog post.
####################################### | |
# Displays a yes/no prompt to continue that repeats until input matches. | |
# Arguments: | |
# $1 - (optional) a string representing the yes/no question to ask | |
# $2 - (optional) a string representing the prompt style. | |
# Returns: | |
# 0 to proceed further (indicates "yes"), 1 to stop (indicates "no"). | |
####################################### | |
continue_prompt() { | |
local prompt default reply |
// @ts-check | |
"use strict" | |
/** | |
* Set up datadog tracing. This should be called first, so Datadog can hook | |
* all the other dependencies like `http`. | |
*/ | |
function setUpDatadogTracing() { | |
const { tracer: Tracer } = require('dd-trace') | |
const tracer = Tracer.init({ |
Example docker compose file
version: "3"
services:
caddy:
build:
context: .
dockerfile: service/caddy/dockerfile
image: mojzu/dev-caddy:latest
In the olden days, HTML was prepared by the server, and JavaScript was little more than a garnish, considered by some to have a soapy taste.
After a fashion, it was decided that sometimes our HTML is best rendered by JavaScript, running in a user's browser. While some would decry this new-found intimacy, the age of interactivity had begun.
But all was not right in the world. Somewhere along the way, we had slipped. Our pages went uncrawled by Bing, time to first meaningful paint grew faster than npm, and it became clear: something must be done.
And so it was decided that the applications first forged for the browser would also run on the server. We would render our HTML using the same logic on the server and the browser, and reap the advantages of both worlds. In a confusing series of events a name for this approach was agreed upon: Server-side rendering. What could go wrong?
In dark rooms, in hushed tones, we speak of colours.