start new:
tmux
start new with session name:
tmux new -s myname
/**********************************************/ | |
/* | |
/* Tomorrow Skin by Ben Truyman - 2011 | |
/* | |
/* Based on Chris Kempson's Tomorrow Theme: | |
/* https://github.com/ChrisKempson/Tomorrow-Theme | |
/* | |
/* Inspired by Darcy Clarke's blog post: | |
/* http://darcyclarke.me/design/skin-your-chrome-inspector/ | |
/* |
The article previously hosted here is now published on my website: My ErgoDox Keyboard.
(aka "errback" or "error first callback")
.DS_Store | |
node_modules | |
.tmp | |
.sass-cache | |
builds/**/images/* |
In React's terminology, there are five core types that are important to distinguish:
React Elements
This is a response to Bill Fisher regarding experience with Flux:
@abdullin Also, can you clarify what you mean by "solution structure"? I am thinking about revising the examples soon.
Currently all flux samples (that I've seen) group files into folders based on technical similarity. For example, stores go with stores, action creators reside in the same folder shared with the other action creators.
This pattern works quite well for smaller projects. It feels especially good for the sample projects of various MVC frameworks, when you have just a bunch of controllers, models and views.
However, as we discovered on some production projects, such approach doesn't scale well. At some point you end up with dozens of technically similar files per folder and logically messy solution.
var Style = React.createClass({ | |
render: function() { | |
var style = assign({}, this.props); | |
delete style.children; | |
return React.createElement( | |
'div', | |
{style: style, children: this.props.children} | |
); | |
} |
var Immutable = require('immutable'); | |
var todos = OrderedMap(); | |
var TodoStore = createStore({ | |
getAll() { return todos; } | |
}); | |
Dispatcher.register(function(action) { | |
if (action.actionType === "create") { | |
var id = createGUID(); |