itsMapleLeaf

import { createRequestHandler } from "@remix-run/express"
import express from "express"

const app = express()
let build

if (process.env.NODE_ENV === "production") {
	build = await import("./build/server/index.js")
	app.use(express.static("build/client"))
} else {

itsMapleLeaf

name: Checks

on:
  push:
    branches:
      - main
  pull_request:

jobs:
  check:

itsMapleLeaf

import type { Truthy } from "./types.ts"

class ExtendedIterable<T> implements Iterable<T> {
	constructor(private iterable: Iterable<T>) {}

	*[Symbol.iterator]() {
		yield* this.iterable
	}

	apply<U>(fn: (iterable: ExtendedIterable<T>) => Iterable<U>) {

itsMapleLeaf

import { useDebouncedCallback } from "./useDebouncedCallback"

export function Example() {
	const searchDebounced = useDebouncedCallback((query: string) => {
		// do something with query
	}, 500)

	return (
		<input
			onChange={(event) => {

itsMapleLeaf

import { Suspense } from 'react'
import { api } from 'convex/_generated'
import { useQuerySuspense } from './useQuerySuspense'

function App() {
  return (
    <Suspense fallback="Loading...">
      <TodoList />
    </Suspense>
  )

itsMapleLeaf

async function loop() {
  let currentTime = performance.now()
  while (true) {
    const nextTime = await animationFrame()
    const delta = nextTime - currentTime
    // progress += delta
    currentTime = nextTime
  }
}

itsMapleLeaf

import { useCallback, useInsertionEffect, useRef } from "react"

export function useEffectEvent<Args extends unknown[], Return>(
	callback: (...args: Args) => Return,
) {
	const ref = useRef((..._args: Args): Return => {
		throw new Error("Cannot call an event handler while rendering.")
	})

	useInsertionEffect(() => {

itsMapleLeaf

with React, I like being able to describe what my UI should be, top to bottom, depending purely on props and state

with Solid, conceptually, you describe what it starts out as and how it changes over time

in Solid, this manifests as needing to wrap computed values in functions, not being able to destructure props, not being able to use early returns, and so on. I know why it's this way, but it's a tradeoff nonetheless

there's some nice stuff there too though, like how JSX elements are just DOM elements, and there's no need for the "useRef useEffect" dance, and I appreciated that when I tried Solid

all that being said, I still prefer the "start over from scratch on each render" approach, as well as the separation of "UI description" and "imperative bullshit" zones that React gives me. Solid's ecosystem is big enough that I could realistically use it for a project, but ultimately, if rendering was a bottleneck for me, I'd either pick something more React-like, or not use JS/DOM at all 🤷

itsMapleLeaf

function CreateTodoButton() {
  const submit = CreateTodoAction.useSubmit()
  const isSubmitting = CreateTodoAction.useSubmissions().length > 0
  const params = useParams()

  return (
    <button
      type="button"
      title="Create Todo"
      disabled={isSubmitting}

itsMapleLeaf

I think it's fair to expect divergence with an API that was made for browsers being mimicked elsewhere; here it's more about faithfulness and predictability

node-fetch, cross-fetch, undici fetch, deno fetch, etc. these are all faithful to the original API, and behave in ways that wouldn't surprise you if you're familiar with fetch. the more unfamiliar nooks and crannies of the API (e.g. ReadableStream) is sort of a rats nest unfortunately 😅 but that's beside the point

here's the difference with Next.js: now I'm not writing fetch with fetch in mind, I'm writing fetch with Next.js's caching behaviors in mind, and a hidden fetch call multiple levels down in the stack can unexpectedly change that behavior in potentially unexpected ways

happy to be convinced otherwise though. I know y'all give this a lot of thought, but this was just really out of left field for me 🫠