indiesquidge

export class UserList extends React.Component {
  state = { count: 0 };

  handleClick = (item) => {
    setTimeout(() => {
      console.log(`You clicked ${this.props.group} ${this.state.count} times`);
    }, 3000);
  };

  render() {

indiesquidge

Reach UI Philosophy

Reach UI is an accessible foundation for React applications and design systems.

The three equally important goals are to be:

• Accessible
• Composable
• Stylable

indiesquidge

#!/usr/local/bin/node

/*
 * Usage: in-place deletion of duplicate files within a folder.
 * ```
 * ./deleteDuplicates.js relative/folder/path/of/duplicate/files
 * ```
 *
 * You may need to change the access control to run this as an executable.
 * ```

indiesquidge

I've been using controlled components for near everything in my application as that has been the recommended way to go, and I subscribe to the idea that React should be in control of this state when possible.

However, I recently went through @ryanflorence's Advanced React course—which is a wonderful collection and breakdown of some powerful (and still uncommon) patterns available in React—and the last lecture is on controlled components.

At around 17:40 in the lecture video, Ryan does something very interesting. He writes some code that looks like this:

<Tabs
  defaultActiveIndex={this.state.currentTab}
 onChange={(index) =&gt; {

indiesquidge

const rawCategories = {
  'hierarchical_categories.level_1': {
    'Beverages': 349,
    'Coffee & Tea': 4,
    'Deli': 35
  },
  'hierarchical_categories.level_2': {
    'Beverages > Energy & Sports Drinks': 54,
    'Beverages > Juice & Nectars': 111,
    'Deli > Cheeses': 30

indiesquidge

import React, { Component } from 'react'
import api from './api'

class App extends Component {
  constructor () {
    super()
    this.state = {
      name: null,
      imgUrl: null
    }

indiesquidge

import React, { Component } from 'react';

class App extends Component {
  constructor () {
    super()
    this.state = {
      name: null,
      imgUrl: null
    }
  }

indiesquidge

Advanced React by React Training

Personal notes while working through Advanced React: https://courses.reacttraining.com/p/advanced-react

Granted this is a contrived example, but it's still something I took notice to: in those "Advanced React" videos I've been watching, Ryan Florence codes very slowly, and does not make one quick change and jump back to the browser to see what changed.

He stops and thinks. He asks himself (or the viewer) questions. He wonders what

indiesquidge

There are a myriad of benefits of smaller PRs with smaller line change deltas:

• easier for reviewers, not only in sheer amount of code to review, but also in the ability to provide useful feedback or start a discussion around different architecture patterns
• lower chances of bugs creeping in
• simpler to refactor and iterate upon
• encourages the code author to think more iteratively (e.g. what is the API I am trying to add right now? What will it look like when I'm done? Is what I'm doing extensible? Will it be suitable for future extensions, etc.)
• more synonymous with a CI flow; it is better to ship multiple small things that can easily be cherry-picked or reverted than it is to ship big PRs that are harder to debug and roll back

One pitfall to small PRs is people feeling like they can't move ahead or build on top of code that is up for review.

indiesquidge

Status	Type	Env Vars Change	Review App	Ticket
Ready/Hold	Feature/Bug/Tooling/Refactor/Hotfix	Yes/No	Link	Link

⚠️ NOTE: use notes like this to emphasize something about the PR. This could include other PRs this PR is built on top of; new or removed environment variables; reasons for why the PR is on hold; or anything else you would like to draw attention to.

Problem

What problem are you trying to solve?