Microsoft To-Do

We connect

every tiny single component

to the store

Think MVVM or MVP

Model Passing

Model Passing

1. Data hierarchy == View hierarchy
2. Expensive updates
3. Very sensitive to changes
4. Where do I add child data?
5. Derived data dependencies
6. Does not scale (too many things)

Primitives Passing

Primitives Passing

1. Data hierarchy == View hierarchy
2. Expensive updates
3. Sensitive to changes
4. Where do I add child data?
5. Derived data dependencies
6. Does not scale (too many things)

ICC

ICC

1. Data hierarchy == View hierarchy
2. Expensive updates
3. Sensitive to changes
4. Where do I add child data?
5. Derived data dependencies
6. Does not scale (too many things)
7. Performance?

Performance

Worry not!

Our context

ICC
react-redux < v5.0.0

No Batcher + ICC
react-redux < v5.0.0

No Batcher + ICC
react-redux v5.0.0beta3

Single Subscribe
react-redux v5.0.0beta3

Rendering (dev build)

Single Subscribe

react-redux v5.0.0beta3

ICC + virtualized list
react-redux v5.0.0beta3

Total time (perf build)

More components    =    less overhead

What we have learned?

What we have learned?

Every connect()

adds

~0.1ms to initial rendering time

What we have learned?

State Passing is  ~10% faster in our hot rendering path 🔥but ...

Single file with ~50 selectors and 25 handlers 🙀

What we have learned?

What we have learned?

Measure in your own case 🔎

Use virtualized lists 📜

Do not create custom Batchers 💩

Compose behaviours with React components mindfully

ICC in the wild

Using ICC

import AddTask from 'components/AddTask'

// Component stuff ...
render() {
  return (
    <AddTask intentOrigin={ intentOrigin } />
  )
}

ICC in the wild - default/index

import React from 'react'
import AddTask from '../AddTask'
import connect from '../connect'
import '../addTask.styl'

export default connect(AddTask)

ICC in the wild - connect

import { connect } from 'react-redux'
import ...

const mapStateToProps = createSelector(
  getAddTask,
  ...,
  (addTask, ...) => ({
    title: addTask.title,
    ...
  })
)

const mapActionsToProps = dispatch => ({
  onChange: ({ title }) => dispatch(updateAddTask({ title })),
  ...
})

export default connect(mapStateToProps, mapActionsToProps)

ICC in the wild - Component

import React, { PropTypes } from 'react'
...

export default class AddTask extends React.Component {
  // ...

  render() {
    const { title, onFocus, onPlusClick, isFocused } = this.props
    const placeholder = LocalizedString.getString('placeholder_add_task')

    return (
      <div className="addTask">
        <button
          className="addTask-icon"
          onClick={ onPlusClick }
        >
          <Icon name={ iconName }/>
        </button>
        // ...
      </div>
    )
  }
}

Another Example

import React, { PropTypes } from 'react'
import TaskItem from '../TaskItem'
import connect from './connect'

import Checkbox from 'components/Checkbox'

const DefaultTaskItem = props =>
  <TaskItem
    primaryActionComponent={ <Checkbox id={ props.id } intentOrigin={ props.intentOrigin }/> }
    { ...props }
  />

DefaultTaskItem.propTypes = {
  id: PropTypes.string.isRequired,
  inToday: PropTypes.bool,
  intentOrigin: PropTypes.string
}

export default connect(DefaultTaskItem)

Directory structure

===

state structure

Think "a table in relational DB"

What's next?

1. Separate builds for integrations (logic/UI reuse) 🤔

2. Cyclic dependencies in Webpack  💩

3. Too much code for derived data

4. "Where do I put that?" 

More structure

Relationships

Read (domain - domain) dependencies

Transactions

Write (domain->domain) relationships

State machines?

Going deeper...

Basics

📜 First Normal Form

📜 Data Domain

📜 Hexagonal architecture

📜 Database Normalization Explained

📜 Avoiding Accidental Complexity
When Structuring Your App State

📜 Shape Your Redux Store Like Your Database

Advanced

📜 DDD - Domain-Driven Design

📜 CQRS Explained

📜 DSL - Domain Specific Language

📖 DDD Distilled

Black Magic

📼 Entity-Component-System

📜 Functional microservices

📜 Statecharts