indiesquidge

Plain JavaScript objects are better than classes when they can be used, and many popular modern frameworks have adopted their use.

Consider that in React a component can be created as either a class or as an object.

// using a class
class Welcome extends React.Component {
  render() {
 Hello, {this.props.name}

indiesquidge

Pull Requests & Reviews

Brief Background

People are far less inclined to "drudge" through a review if they have no clue or context as to what they are reviewing.

Details and descriptions are paramount for PRs that include things like lots of new logic, lots of deletions, and/or new files.

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?

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

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

import React, { Component } from 'react';

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

indiesquidge

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

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

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

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

#!/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.
 * ```