[10:57 PM] acemarke: so, the canonical "bad perf for React+Redux" example is a todo list of 10,000 items
[10:58 PM] Sinistral: I always thought passing an object through was just a typical JS pointer
[10:58 PM] acemarke: the trivially obvious store shape is a single array of all 10K todo objects
[10:58 PM] acemarke: with a single connected list component
[10:58 PM] Sinistral: eh, ignore me, finish
[10:59 PM] acemarke: the list's mapState retrieves the array, and the list component renders this.props.todos.map(todo => <TodoListItem todo={todo} /> )
[10:59 PM] acemarke: which works fine the first time around
[10:59 PM] acemarke: but if you edit, say, the "text" field in a single todo
[11:00 PM] acemarke: your reducer returns a new updated todo object inside of a new array reference, shallow-copied
[11:00 PM] Sinistral: You are re-drawing the enti...oh
class ChildComponent extends React.Component { | |
constructor(props) { | |
super(props); | |
this.state = { | |
counter : 0 | |
}; | |
this.onButtonClick = this.onButtonClick.bind(this); | |
} | |
// copy-pasta'd from isarray | |
var toString = {}.toString; | |
const isArray = Array.isArray || function (arr) { | |
return toString.call(arr) == '[object Array]'; | |
}; | |
export function batchedSubscribe() { | |
let currentListeners = []; |
import React from "react"; | |
import ReactDOM from "react-dom"; | |
import configureStore from "./store/configureStore"; | |
const store = configureStore(); | |
const rootEl = document.getElementById("root"); |
class ParentComponent extends Component { | |
constructor() { | |
super(); | |
this.state = { | |
data : [ | |
{id : 1, date : "2014-04-18", total : 121.0, status : "Shipped", name : "A", points: 5, percent : 50}, | |
{id : 2, date : "2014-04-21", total : 121.0, status : "Not Shipped", name : "B", points: 10, percent: 60}, | |
{id : 3, date : "2014-08-09", total : 121.0, status : "Not Shipped", name : "C", points: 15, percent: 70}, | |
{id : 4, date : "2014-04-24", total : 121.0, status : "Shipped", name : "D", points: 20, percent : 80}, |
[04:52 PM] acemarke: Question for y'all. I'm trying to define some semi-official-ish terminology for common types of functions that show up when writing reducer logic
The original reason for the term "reducer" is that it takes (state, action)
and returns the new state, same as a callback to reduce()
Does it make sense to still use the word "reducer" when describing functions that are used inside of reducer logic, but do not have the exact (state, action)
signature?
[04:57 PM] acemarke: Some examples might be:
- a function that handles a "cross-slice" action, like
const newSliceA = handleSomeCase(state.a, state.b)
- A function that handles a specific pattern that occurs inside of multiple cases, and each case calls this function to do part of the work
[05:22 PM] totaldis: how is that a reduce?
[05:22 PM] acemarke: that's kinda what I'm asking
people generally throw around the phrase "reducers" to mean "any function at all that gets called somewhere inside that log
import { take, put, call, fork, cancel, cancelled } from 'redux-saga/effects' | |
import {EVENT_POLLING_START, EVENT_POLLING_STOP} from "constants/eventPolls"; | |
import {ClientEventType} from "constants/serverEvents"; | |
function* handleEventA(serverEvent) { | |
yield put({type : serverEvent.type, payload : {name : serverEvent.eventAData}}); | |
} |
[02:06 PM] acemarke: @Steven : a couple other thoughts on the whole NODE_ENV
thing. First, per my comments, it really is a Node concept. It's a system environment variable that Node exposes to your application, and apparently the Express web server library popularized using its value to determine whether to do optimizations or not
[02:08 PM] acemarke: Second, because of its use within the Node ecosystem, web-focused libraries also started using it to determine whether to they were being run in a "development" environment vs a "production" environment, with corresponding optimizations. For example, React uses that as the equivalent of a C #ifdef
to act as conditional checking for debug logging and perf tracking. If process.env.NODE_ENV
is set to "production"
, all those if
clauses will evaluate to false
.
Third, in conjunction with a tool like UglifyJS that does minification and removal of dead code blocks, a clause that is surrounded with if(process.env.NODE_ENV !== "development")
[09:38 PM] Steven: No matter what I do, I cannot get the NODE_ENV to be production for the purposes of webpack compiling
I have tried every example on the web
plugins: [
new webpack.DefinePlugin({
'process.env':{
'NODE_ENV': JSON.stringify('production')