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
- Using emmet in jsx files
- Emmet expands text when js autocomplete needed
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
This year marks the first year that we are doing full scale rendering of our SPA application on our mobile.walmart.com Node.js tier, which has provided a number of challenges that are very different from the mostly IO-bound load of our prior #nodebf.
The infrastructure outlined for last year is the same but our Home, Item and a few other pages are prerendered on the server using fruit-loops and hula-hoop to execute an optimized version of our client-side JavaScript and provide a SEO and first-load friendly version of the site.
To support the additional CPU load concerns as peak, which we hope will be unfounded or mitigated by our work, we have also taken a variety of steps to increase cache lifetimes of the pages that are being served in this manner. In order of their impact:
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.
The MIT License (MIT) | |
Copyright (c) 2014 Tomas Kafka | |
Permission is hereby granted, free of charge, to any person obtaining a copy | |
of this software and associated documentation files (the "Software"), to deal | |
in the Software without restriction, including without limitation the rights | |
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell | |
copies of the Software, and to permit persons to whom the Software is | |
furnished to do so, subject to the following conditions: |
var If = React.createClass({ | |
render: function() { | |
return this.props.value && this.props.children; | |
} | |
}); | |
// usage | |
<If value={this.state.whatever}> | |
Stuff | |
</If> |
I've been struggling to come up with a good pattern for handling loading state in Flux (specifically using Fluxxor, though I think this is an issue for any implementation).
When I say "loading state," what I mean is state in a store that tracks:
Here's my first (very simple) pass at this, a store mixin called LoadingStoreMixin.js
:
document.addEventListener("DOMContentLoaded", function(event) { | |
/* | |
Later you can easily change this to any other PubSub library you like. | |
var _pubSub = PubSub; | |
or you can even wrap it to define your own API. This way, later on | |
you can still continue to use _ps.sub and _ps.pub even if you change | |
out the library defining that behaviour. Let's go with the latter. |
'use strict'; | |
var React = require('react'); | |
function createAsyncHandler(getHandlerAsync, displayName) { | |
var Handler = null; | |
return React.createClass({ | |
displayName: displayName, |