devinrhode2

const { safeEnv } = require('./src/env')

// Note: NextConfig type allows any keys, so we are plucking the specific keys we want to type-check.
/**
 * @type {Pick<
 *   import('next').NextConfig,
 *   | 'webpack'
 *   | 'env'
 * >}
 */

evanrs

When it comes to memo'ization any option will be valid if it meets the following three criteria.

1. Will this work be closer to the root, or the leaf?

As we approach the leaves of the component tree the impact of memo'ization will be diminished as the number of impacted children decreases.

As the number of potential children increases we offer a corresponding level of care in making sure our values only update when there's a pertinent change to that value.

2. Where will my work be used?

zhuowei

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<!-- not sure which one it is, so set both -->
	<key>Ensemble</key>
	<dict>
		<key>Enabled</key>
		<true/>
	</dict>

Phate6660

Cryptography

https://github.com/spieglt/cloaker - password-based file encryptor (NOTE: uses Qt)
https://github.com/str4d/rage - file encryption tool and librarary that uses the age format

Media

https://github.com/mohanson/gameboy - gameboy emulator
https://github.com/bartwillems/lyriek - fetch the lyrics of a song playing in an mpris-compatible player
https://github.com/JakeStanger/mpd-discord-rpc - discordrpc for mpd

evanrs

type ArityNone<T> = () => T;
type ArityOne<T, A> = (a?: A) => T;
type ArityTwo<T, A, B> = (a: A, b?: B) => T;
type ArityThree<T, A, B, C> = (a: A, b: B, c?: C) => T;
type ArityFour<T, A, B, C, D> = (a: A, b: B, c: C, d?: D) => T;

export function once<T>(resolver: ArityNone<T>): ArityNone<T>;
export function once<T, A>(resolver: ArityOne<T, A>): ArityOne<T, A>;
export function once<T, A, B>(resolver: ArityTwo<T, A, B>): ArityTwo<T, A, B>;
export function once<T, A, B, C>(resolver: ArityThree<T, A, B, C>): ArityThree<T, A, B, C>;

bvaughn

useSubscription and useMutableSource¹ tearing and deopt behavior.

Mounting a new tree

The tree below represents a React application mounting. During mount, two components read from an external, mutable source. The first one (List) reads version 1 of that data and the second one (Item) reads version 2.

Deopt

useSubscription (legacy mode)

N/A.

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

githendrik

{
  ".ts": {
    "parser": "typescript",
    "style": "angular-alternative"
  }
}

timvisee

Falsehoods programmers believe about time

This is a compiled list of falsehoods programmers tend to believe about working with time.

Don't re-invent a date time library yourself. If you think you understand everything about time, you're probably doing it wrong.

Falsehoods

• There are always 24 hours in a day.
• February is always 28 days long.
• Any 24-hour period will always begin and end in the same day (or week, or month).

mfd