Microsoft Developer Advocate for Internet Explorer. Contributing Editor to Smashing Mag.
How can I know developers pain points without working in the same environment as developers. That's why I use a Mac.
// ------------ | |
// counterStore.js | |
// ------------ | |
import { | |
INCREMENT_COUNTER, | |
DECREMENT_COUNTER | |
} from '../constants/ActionTypes'; | |
const initialState = { counter: 0 }; |
Microsoft Developer Advocate for Internet Explorer. Contributing Editor to Smashing Mag.
How can I know developers pain points without working in the same environment as developers. That's why I use a Mac.
import React from 'react' | |
import assign from 'object-assign' | |
var styles = {} | |
class Autocomplete extends React.Component { | |
static propTypes = { | |
initialValue: React.PropTypes.any, | |
onChange: React.PropTypes.func, |
param( | |
[Parameter(Mandatory=$true)][string]$pathToBeAdded | |
) | |
$local:oldPath = get-content Env:\Path | |
$local:newPath = $local:oldPath + ";" + $pathToBeAdded | |
set-content Env:\Path $local:newPath |
Hi Nicholas,
I saw you tweet about JSX yesterday. It seemed like the discussion devolved pretty quickly but I wanted to share our experience over the last year. I understand your concerns. I've made similar remarks about JSX. When we started using it Planning Center, I led the charge to write React without it. I don't imagine I'd have much to say that you haven't considered but, if it's helpful, here's a pattern that changed my opinion:
The idea that "React is the V in MVC" is disingenuous. It's a good pitch but, for many of us, it feels like in invitation to repeat our history of coupled views. In practice, React is the V and the C. Dan Abramov describes the division as Smart and Dumb Components. At our office, we call them stateless and container components (view-controllers if we're Flux). The idea is pretty simple: components can't
var pureRender = (Component) => { | |
Object.assign(Component.prototype, { | |
shouldComponentUpdate (nextProps, nextState) { | |
return !shallowEqual(this.props, nextProps) || | |
!shallowEqual(this.state, nextState); | |
} | |
}); | |
}; | |
module.exports = pureRender; |
Note: This is the first time we're sharing meeting notes publicly. The primary reason we haven't shared these is because we often mix public discussions with matters that are Facebook specific and should not be public. We're really trying to be more open about our development process and what's happening inside the project so moving forward, we'll be sharing meeting notes. While most of us do work at Facebook, we're committed to this being an open project - for now we'll filter out the private notes from the public notes. Hopefully we can make it possible for these meetings to be open to any who wish to attend.
Attendees:
[ | |
// | |
// TABS (REGULAR) | |
// | |
// Tab set | |
{ | |
"class": "tabset_control", | |
"layer0.texture": "", |
TLDR: a React component should either manage its own state, or expose a callback so that its parent can. But never both.
Sometimes our first impulse is for a component to entirely manage its own state. Consider this simple theater seating picker that has a letter for a row, and a number for a seat. Clicking the buttons to increment each value is hardly the height of user-interface design, but never mind - that's how it works:
/* @flow */
var React = require('react');
var Letter: React.ReactClass = React.createClass({
getInitialState: function(): any {
This is no longer needed as Emmet supports JSX - you just need to turn it all on. Did a quick tutorial: http://wesbos.com/emmet-react-jsx-sublime/
Thanks, @wesbos