timc1

import * as React from "react";

type Theme = "system" | "light" | "dark";

const STORAGE_KEY = "theme";
const VALID_THEMES: Theme[] = ["system", "light", "dark"];
const DARK_MODE_MEDIA_QUERY = "(prefers-color-scheme: dark)";

function getAppTheme(): Theme {
  if (typeof window !== "undefined") {

rlespinasse

#!/usr/bin/env bash
set -eo pipefail
set -u
IFS=$'\n\t'

command -v fzf >/dev/null 2>&1 || {
  echo >&2 "I require fzf but it's not installed.  Aborting."
  exit 1
}

slikts

Advanced memoization and effects in React

Memoization is a somewhat fraught topic in the React world, meaning that it's easy to go wrong with it, for example, by [making memo() do nothing][memo-pitfall] by passing in children to a component. The general advice is to avoid memoization until the profiler tells you to optimize, but not all use cases are general, and even in the general use case you can find tricky nuances.

Discussing this topic requires some groundwork about the technical terms, and I'm placing these in once place so that it's easy to skim and skip over:

• Memoization means caching the output based on the input; in the case of functions, it means caching the return value based on the arguments.
• Values and references are unfortunately overloaded terms that can refer to the low-level implementation details of assignments in a language like C++, for example, or to memory

tomhicks

/*
Copy this into the console of any web page that is interactive and doesn't
do hard reloads. You will hear your DOM changes as different pitches of
audio.

I have found this interesting for debugging, but also fun to hear web pages
render like UIs do in movies.
*/

const audioCtx = new (window.AudioContext || window.webkitAudioContext)()

emmabostian

Seven different types of CSS attribute selectors

// This attribute exists on the element
[value]

// This attribute has a specific value of cool
[value='cool'] 

// This attribute value contains the word cool somewhere in it
[value*='cool'] 

kripod

import React from 'react';

// Source: https://github.com/emotion-js/emotion/blob/master/packages/styled-base/types/helper.d.ts
type PropsOf<
  // eslint-disable-next-line @typescript-eslint/no-explicit-any
  E extends keyof JSX.IntrinsicElements | React.JSXElementConstructor<any>
> = JSX.LibraryManagedAttributes<E, React.ComponentPropsWithRef<E>>;

export interface BoxOwnProps<E extends React.ElementType = React.ElementType> {
  as?: E;

surma

node_modules
build
package-lock.json

IanColdwater

Mute these words in your settings here: https://twitter.com/settings/muted_keywords

ActivityTweet
generic_activity_highlights
generic_activity_momentsbreaking
RankedOrganicTweet
suggest_activity
suggest_activity_feed
suggest_activity_highlights
suggest_activity_tweet

sebmarkbage

I heard some points of criticism to how React deals with reactivity and it's focus on "purity". It's interesting because there are really two approaches evolving. There's a mutable + change tracking approach and there's an immutability + referential equality testing approach. It's difficult to mix and match them when you build new features on top. So that's why React has been pushing a bit harder on immutability lately to be able to build on top of it. Both have various tradeoffs but others are doing good research in other areas, so we've decided to focus on this direction and see where it leads us.

I did want to address a few points that I didn't see get enough consideration around the tradeoffs. So here's a small brain dump.

"Compiled output results in smaller apps" - E.g. Svelte apps start smaller but the compiler output is 3-4x larger per component than the equivalent VDOM approach. This is mostly due to the code that is usually shared in the VDOM "VM" needs to be inlined into each component. The tr

sleepyfox

'Users hate change'

This week NN Group released a video by Jakob Nielsen in which he attempts to help designers deal with the problem of customers being resistant to their new site/product redesign. The argument goes thusly:

1. Humans naturally resist change
2. Your change is for the better
3. Customers should just get used to it and stop complaining

There's slightly more to it than that, he caveats his argument with requiring you to have of course followed their best practices on product design, and allows for a period of customers being able to elect to continue to use the old site, although he says this is obviously only a temporary solution as you don't want to support both.