React v0.13 released
facebook.github.io
facebook.github.io
Now all I need to do is sort out some issues with dispatch and I'm good to go...
Of course, the big thing we're all waiting for is Native. If that truly offers a bridge, rather than a wrapper, to native APIs from Javascript, then it will be a game-changer.
https://github.com/ericclemmons/react-resolver/issues/8#issu...
(We know people are excited about React Native and we're working hard to get it out the door – keep your eyes peeled!)
This is the pattern that the Flux library I wrote uses: https://github.com/acdlite/flummox/blob/master/docs/api/Flux...
I wrote also wrote a bit about why components are generally preferable to mixins: https://github.com/acdlite/flummox/blob/master/docs/why-flux...
I'm getting pretty excited to start working with React Native either way.
class Foo { constructor() { this.whatever = 4; }
bar() {
this.whatever = 3;
}
}var foo = new Foo();
blah.onSomeEvent(foo.bar);
// When SomeEvent is triggered on blah, `this` will refer to blah, not foo.
console.log(blah.whatever); // 3 console.log(foo.whatever); // 4
// You have to: blah.onSomeEvent(foo.bar.bind(foo));
console.log(blah.whatever); // undefined console.log(foo.whatever); // 3
Which I know is just traditional JS, but it's a little unexpected because that's not how most OO languages operate.
function Bar() {
Foo.call(this);
}
Bar.prototype = Object.create(Foo.prototype);
Bar.prototype.constructor = Bar;
Foo.prototype.thing = function() { ....
What other "approach" to prototypical inheritance is there in JavaScript? The module pattern doesn't use prototypes.It would be great to know what the benefits are vs declaring function literals on an object, or declaring a function directly on Bar's prototype.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inhe...
ES6's class system is infinitely better.
function super(obj, method) {
for (var p = obj.prototype; p; p = p.prototype)
if (p[method])
return p[method];
throw method+" not found";
}
then use: subclass.prototype.overridden = function(x,y) {
super(this, 'some_overriden_method').call(this, x, y);
// ...
}
If so, that means it's just sugar. If not, what does it do differently?- Harder to screw up. Even if you know what you're doing, prototypical inheritance involves several steps which can get repetitive.
- Interoperable with non-es6 "classes". It's not like you're losing anything.
There is nothing sad about React PATENTS file.
1. React source code is licensed under the Modified BSD license.
2. React also comes with a conditional patent grant. Here "conditional" means that the patent grant may terminate under some conditions. It does not terminate 1.
Most BSD and MIT-licensed software you use comes without a patent grant at all.
Still sad?
If you the licensee also consider Modified BSD to have an implicit patent grant then the React patent grant is much worse for you than if it hadn't existed.
Guess I'm less less-informed now.
If Facebook doesn't intend to assert its patents aggressively, why does it want to prevent users of React from defending themselves?
Granting patents in the context of permissively licensed open source is a generous act and making the grant conditional is a way of not giving up your ability to form the strongest possible defense when you're brought into patent litigation. If you have been following along the recent years events (where is that patent apocalypse, anyone?) then it should be no surprise why companies need to do that.
Conditional patent grants are not new. Apache License v2.0 has a conditional patent grant [http://www.apache.org/licenses/LICENSE-2.0]. Google added a conditional patent grant to WebM, complementing its Modified BSD license [http://www.webmproject.org/license/additional/]. Google's Dart project is licensed under Modified BSD and has a.. you guessed it - conditional patent grant [https://code.google.com/p/dart/source/browse/trunk/dart/PATE...].
Apache, GPL, MPL, etc. have retaliation clauses that terminate your patent license only if you sue (or in some cases, countersue) in relation to the covered software. Facebook's patent grant says you can never sue Facebook, while being vulnerable to being sued by Facebook for anything but React.
Edited for clarity.
But I'm not sure I agree with your conclusion though.
Scenario one: MYCOMP uses React in a product, decides to sue FB because FB uses the term "It's complicated" which MYCOMP was granted a patent for by the US patent office (the phrase was translated into a dual-ROT13-machine for the purpose of the patent application). MYCOMP had tried to get FB to pay them a reasonable license fee prior to suing but Facebook neglected. Now MYCOMP does not have a patent grant for their use of React any longer but isn't that then ~similar to as if React didn't have any patent grant to begin with (from a litigation perspective) - like most MIT and BSD licensed software we use? Had I been with BIGCORP I'd have asked the legal folks or our favorite patent attorney but now I'm solo so I'm throwing out the question here for further discussion.
Scenario two: FB sues UCOMP (who uses React in one of their products) for patent infringement of FB's "Send message from client to server" patent (nicely masqueraded in the patent application). UCOMP decides to counter-sue and we have a situation similar to scenario one.
https://github.com/Raynos/mercury
All react best practices converge on what mercury has done out of the box since day one. React's advantage is it's community. There are more docs, examples and tutorials.
As I mentioned in another comment on this thread, many mixins can be implemented as higher-order components that we call "containers". Many others relate to data fetching, so we're looking at adding first-class support for data subscriptions which can replace even more uses of mixins. (And in my experience, it's rare to add mixins to a component after it's written.)
ES6 classes aren't suitable for everyone yet ("Ask your doctor if ES6 classes…") but they're a new API which is more convenient for some use cases, so we chose to add it now instead of waiting until we're at perfect feature parity to give people the chance to use the new syntax.
Subclassing would help a ton here.
There are ways to go around the need for a mixin, usually through composition, so with a certain coding style you might not need mixins at all.
But I also miss it, yeah, very useful addon.
> React.addons.classSet is now deprecated. This functionality can be replaced with several freely available modules. classnames is one such module.
it's a backhanded compliment.
what they're actually saying is, React is getting even faster while other frameworks try are playing catch-up.
Performance is still something that every framework is striving to optimize - this is only a good thing when teams announce that they are working to improve their performance, mobile is still hard with the DOM.
Each of the frameworks draw positive influences from each other, and don't hesitate to give each other credit - the React team praised the idea behind ng-animate for programmatic CSS transitions, the Angular team directly drew from React for the idea of unidirectional flow for Angular 2 and built on top of Ember's route-recognizer for the new router.
Isn't that true?