tmbtech

/* eslint no-undef: 0*/
/* eslint react/jsx-no-undef: 0*/
import React from "react"

const chart = {
  id: "purchase",
  initial: "fetchingWorkshopData",
  states: {
    fetchingWorkshopData: {
      on: {

tmbtech

#!/bin/sh

# More Mac setup at https://mac.iamdeveloper.com

# Log file
timestamp=$(date +%s)
logFile="./my-mac-setup-$timestamp.log"

# if true is passed in, things will reinstall
reinstall=$1

tmbtech

What I Wish I'd Known About Equity Before Joining A Unicorn

Disclaimer: This piece is written anonymously. The names of a few particular companies are mentioned, but as common examples only.

This is a short write-up on things that I wish I'd known and considered before joining a private company (aka startup, aka unicorn in some cases). I'm not trying to make the case that you should never join a private company, but the power imbalance between founder and employee is extreme, and that potential candidates would

tmbtech

// put this at the top of your app
const setState = Component.prototype.setState
Component.prototype.setState = function(nextState) {
  console.group(this.constructor.name)
  console.trace()
  if (this.shouldComponentUpdate) {
    console.log('shouldComponentUpdate', (
      this.shouldComponentUpdate(this.props, nextState)
    ))
  }

tmbtech

import React from "react";
import { isEqual } from "underscore";

/**
 * HOC for diagnosing unnecessary renders and identifying faulty selectors
 *
 * Adds a logger function to a component that lists all changed props
 * Also checks if changed props are deeply equal
 *
 * Usage: Decorate the component you are investigating with renderDoctor:

tmbtech

These examples are presented in an attempt to show how each coding styles attempts to or does not attempt to isolate side-effects. There are only 2 semantic elements in a barebone "Hello World" implementation:

• Invocation of console.log
• Declaration of HELLO_WORLD

Since every coding style can abstract away data into a parameter or variable, there is no point for us to show that. All implementations assume HELLO_WORLD is a constant that is always inlined. This way it reduces the variations we need to present. (To make an anology, if we were to implement incrementByOne, would we need to inline the number 1 or pass it in as parameter?)

CAVEAT/LIMITATION: All implementations also assume console is static. In case of OOP inheritance, Console is assumed to be extendable. In case of functional programming, console.log is asumed to be a function that can be passed around without further modification.

Declarative

tmbtech

ES6 Defaults / Overrides Pattern

Combine default parameters and destructuring for a compact version of the defaults / overrides pattern.

function foo ({
    bar = 'no',
    baz = 'works!'
  } = {}) {

tmbtech

import React, { Component } from 'react';
import { createStore, combineReducers, applyMiddleware, bindActionCreators } from 'redux';
import { provide, connect } from 'react-redux';
import thunk from 'redux-thunk';

const AVAILABLE_SUBREDDITS = ['apple', 'pics'];

// ------------
// reducers
// ------------

tmbtech

The 0.13.0 improvements to React Components are often framed as "es6 classes" but being able to use the new class syntax isn't really the big change. The main thing of note in 0.13 is that React Components are no longer special objects that need to be created using a specific method (createClass()). One of the benefits of this change is that you can use the es6 class syntax, but also tons of other patterns work as well!

Below are a few examples creating React components that all work as expected using a bunch of JS object creation patterns (https://github.com/getify/You-Dont-Know-JS/blob/master/this%20&%20object%20prototypes/ch4.md#mixins). All of the examples are of stateful components, and so need to delegate to React.Component for setState(), but if you have stateless components each patterns tends to get even simpler. The one major caveat with react components is that you need to assign props and context to the component instance otherwise the component will be static. The reason is

tmbtech

If you've reached this page, it's probably because your "parent-based and owner-based contexts differ".

As we've been iterating on React's "context" feature, we've discovered that the parent-based relationship is more useful than the owner-based relationship, so we're migrating to use a parent-based hierarchy.

In short, the owner of a component is whomever creates the component, while the parent of a component is whomever would be the containing ancestor in the DOM hierarchy. To learn more about the owner relationship, see the docs here: http://facebook.github.io/react/docs/multiple-components.html

In many cases, the owner and the parent are the same node, in which case, no further action is necessary. However, if your owner and your parent differ, you should ensure that the context variables you're using aren't going to break when we switch from owner-based contexts to parent-based contexts. If you're seeing the warning, your component may not be ready for the switch.

NOTE: semantically-equal context var