garybernhardt

(Chapters marked with * are already written. This gets reorganized constantly
and 10 or so written chapters that I'm on the fence about aren't listed.)

Programmer Epistemology
  * Dispersed Cost vs. Reduced Cost
  * Verificationist Fallacy
  * Mistake Metastasis
  The Overton Window
  Epicycles All The Way Down
  The Hyperspace Gates Were Just There

justinwoo

/*
The default behavior of React is actually not very fast.

This is especially the case when you have a list or table with lots of elements to represent data.
Most of the data may not be changing, but the portions that do will need to get data passed down
from the parent. But since the parent needs to render all the siblings of the changed element,
having React reuse render() results on the siblings that haven't changed is very useful.

Good React Components are functions of only their props and state, and in those cases you will
inevitably end up going through the same render() calls which are unnecessary and they provide the

oakes

Contents

• Why care about Rust?
• The Toolchain
• Creating a New Project
• Modules
• Crates
• Types
• References
• Mutability

sebmarkbage

import { Component } from "React";

export var Enhance = ComposedComponent => class extends Component {
  constructor() {
    this.state = { data: null };
  }
  componentDidMount() {
    this.setState({ data: 'Hello' });
  }
  render() {

jlongster

// Have some complicated non-React widgets that manipulate DOM?
// Do they manage a list of DOM elements? Here's how to wrap it
// into a React component so you can "constantly rerender" it.

// A dumb non-react widget that manually manage some DOM node that
// represent a list of items
function NonReactWidget(node) {
  this.node = node;
}

unnamedd

/**
 *  MacEditorTextView
 *  Copyright (c) Thiago Holanda 2020-2025
 *  https://bsky.app/profile/tholanda.com
 *
 *  (the twitter account is now deleted, please, do not try to reach me there)
 *  https://twitter.com/tholanda
 *
 *  MIT license