wolever

Fractional indexing is a technique for assigning a rank to ordered items, where an item's position can be changed - or a new item introduced - with only one rank value update.

For example, given the items:

{ name: "a", rank: 1 }
{ name: "c", rank: 2 }

With a naive rank ordering scheme, introducing "b" in between "a" and "c" would

0916dhkim

import * as ics from "ics";
import Discord, { GatewayIntentBits, REST, Routes } from "discord.js";
import {Readable} from "stream";
import moment from "moment";
import { z } from "zod";

const eventResponseSchema = z.object({
  id: z.string(),
  name: z.string(),
  description: z.string(),

bramus

🚚 The bookmarklet has moved to https://github.com/bramus/mastodon-profile-redirect/

corradin

trigger:
  - main
pool:
  vmImage: ubuntu-latest

variables:
  npm_config_cache: $(Pipeline.Workspace)/.npm

steps:
  - task: Cache@2

Nooshu

/** @preserve Based heavily on the work by Keith Grant (keithjgrant.com) **/

// IIFE to restrict global namespace
(function(){
    // link to the anonymous avatar
    const ANON_AVATAR = '/images/app-shell/mm.png';
    // cloudinary app code (remember to restrict to set domains in settings)
    const CLOUD_CODE = 'dffhrhuy4';

    // var to store the built HTML

markerikson

import React from 'react';

import Jumbotron from 'react-bootstrap/Jumbotron';
import Alert from 'react-bootstrap/Alert';
import Button from 'react-bootstrap/Button';

import { FallbackProps } from 'react-error-boundary';


interface AEFProps extends FallbackProps {

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

Froelund

import { captureException, flush } from '@sentry/nextjs';
import NextErrorComponent from 'next/error';
import type { ErrorProps } from 'next/error';
import type { NextPage } from 'next';

interface AppErrorProps extends ErrorProps {
  err?: Error;
  hasGetInitialPropsRun?: boolean;
}

andywer

React - Functional error boundaries

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.

Proposed solution

milankorsos

import {Action, ActionCreator, Dispatch} from 'redux';
import {ThunkAction} from 'redux-thunk';

// Redux action
const reduxAction: ActionCreator<Action> = (text: string) => {
  return {
    type: SET_TEXT,
    text
  };
};