ran-dall

# Use an official Python runtime as a parent image
FROM python:3.9-slim

# Install git
RUN apt-get update && \
    apt-get install -y git && \
    rm -rf /var/lib/apt/lists/*

# Set the working directory in the container
WORKDIR /usr/src/app

okikio

const isWorker = typeof WorkerGlobalScope !== 'undefined' && self instanceof WorkerGlobalScope;

async function getHandleFromPath(path: string) {
  const pathParts = path.split('/').filter(part => part.length > 0);
  let currentHandle = await navigator.storage.getDirectory();

  for (const part of pathParts) {
    if (part === '..') {
      currentHandle = await currentHandle.getParent();
    } else {

jacob-ebey

import { html } from "html-tagged";

export default function ClientNavigation() {
  return html`
    <script type="module">
      if (typeof navigation !== "undefined") {
        let lastAbortController;
        navigation.addEventListener("navigate", (event) => {
          if (!event.canIntercept) return;

samselikoff

Remix's useFetcher doesn't return a Promise for any of its methods (like fetcher.submit()) because Remix doesn't want you to explicitly await anything so they can handle things like cancellation for you. Instead, they recommend adding a useEffect and performing whatever logic you need to after the fetcher is in a particular state.

I found using an effect to run some logic after a submission to be too indirect, and there seem to be plenty of cases where you want to submit a form and then perform some other work on the client (sometimes async, like requesting the user's permission for their location), and I'd rather just do that after a submission in the event handler rather than an effect.

So here's a proof of concept hook that wraps Remix's useFetcher and returns a version of submit that is a promise, and resolves with the data from the action:

function useFetcherWithPromise() {
  let resolveRef = useRef();
  let promiseRef = useRef();

joepie91

ES Modules are terrible, actually

This post was adapted from an earlier Twitter thread.

It's incredible how many collective developer hours have been wasted on pushing through the turd that is ES Modules (often mistakenly called "ES6 Modules"). Causing a big ecosystem divide and massive tooling support issues, for... well, no reason, really. There are no actual advantages to it. At all.

It looks shiny and new and some libraries use it in their documentation without any explanation, so people assume that it's the new thing that must be used. And then I end up having to explain to them why, unlike CommonJS, it doesn't actually work everywhere yet, and may never do so. For example, you can't import ESM modules from a CommonJS file! (Update: I've released a module that works around this issue.)

And then there's Rollup, which apparently requires ESM to be u

jonathantneal

/** Return a unique selector for a specific element. */
let getUniqueSelector = (/** @type {Element} */ element) => {
	/** Unique selector for this element */
	let selector = ''

	/** @type {Element} */
	let parent

	/** @type {number} */
	let nth

jonathantneal

/*
| bitmask | enumerable | configurable | writable | accessor |
| ------- | ---------- | ------------ | -------- | -------- |
| 0       |            |              |          |          |
| 1       |    YES     |              |          |          |
| 2       |            |     YES      |          |          |
| 3       |    YES     |     YES      |          |          |
| 4       |            |              |   YES    |          |
| 5       |    YES     |              |   YES    |          |
| 6       |            |     YES      |   YES    |          |

JobLeonard

  const LZuint8Array = (function () {
    /*
      basic ranges of printable UTF16 values (as found in LZ-string): 
        [32, 127), [160, 55296), [63744, 65536)
      We also have filter out string characters like:
      " (34)
      ' (39)
      ` (44)
      (Forward tick is safe: ´ (96))
      So: