So... create-react-class is an unrelated node module. react-create-class (the correct one, I guess) is completely empty, other than the package.json.
[deleted]
React v15.5.0
41–50 of 209 posts
Re: React v15.5.0
#42This is a big deal to deprecate `createClass` and `propTypes`. PropTypes' deprecation is not difficult to handle, but the removal of createClass means one of two things for library maintainers: (1). They'll depend on the `create-class` shim package, or, (2). They must now depend on an entire babel toolchain to ensure that their classes can run in ES5 environments, which is the de-facto environment that npm modules ex…
It's really time to start distributing ES6 via npm. All current browsers support ES6. It's now generally faster than equivalent ES5, it minifies better, tooling is better, etc. It's the app that should compile all the code to run in the target environment if needed. This is what we've done in the new Polymer CLI / polymer-build: we compile all dependencies but only if necessary.
I agree that this is the future. But that will mean telling everyone that they should now run their node_modules through Babel - no inconsequential feat, given the size of the code that must now be transpiled.
Re: React v15.5.0
#43I hate that the React team prefers ES6 classes. This is what I do:
function App(params) { const component = new React.Component(params);
component.lifeCycleMethod = function() {...};
component.render = function() {...};
function privateMethod() {...}
return component;
}Re: React v15.5.0
#44This is a big deal to deprecate `createClass` and `propTypes`. PropTypes' deprecation is not difficult to handle, but the removal of createClass means one of two things for library maintainers: (1). They'll depend on the `create-class` shim package, or, (2). They must now depend on an entire babel toolchain to ensure that their classes can run in ES5 environments, which is the de-facto environment that npm modules ex…
Are you afraid of Babel monopoly? I recommend trying https://buble.surge.sh/ . My life is much better after I started using Buble and bubleify instead of this mess that is Babel.
Come on. Buble is Babel, just with a few presets hardcoded. Yeah, it's better usability, until you need to run a production application.
Re: React v15.5.0
#45So... create-react-class is an unrelated node module. react-create-class (the correct one, I guess) is completely empty, other than the package.json.
Looks like the README on npm is outdated, but https://www.npmjs.com/package/create-react-class seems like the right one.
Re: React v15.5.0
#46So... create-react-class is an unrelated node module. react-create-class (the correct one, I guess) is completely empty, other than the package.json.
They haven't actually moved the deprecated code out into separate packages yet - this is the warning they're about to do so.
The 15.5 announcement does thank several people for "transferring ownership of package names", so I'm guessing that may be one of them.
Re: React v15.5.0
#47I hate that the React team prefers ES6 classes. This is what I do: function App(params) { const component = new React.Component(params); component.lifeCycleMethod = function() {...}; component.render = function() {...}; function privateMethod() {...} return component; }
This is the RevealingModulePattern that Crockford used to advocate back in the day, except assigning to an object that React creates instead of one you create..
http://javascript.crockford.com/private.html
https://addyosmani.com/resources/essentialjsdesignpatterns/b...
Be aware that memory usage can quickly balloon with this pattern, because the GC needs to keep alive anything referenced from inside the closure, including closure objects for the private methods for each individual instantiation of the component. With normal prototypal inheritance, there's only one function object per class; that's the upside of the explicit 'this'. This (and inability of early debuggers to inspect closure variables, which has since been fixed) were what killed this technique in the 2000s.
[Edit: parent post was edited to remove the code sample. I'll keep this up since apparently people are finding it informative, but be aware that I'm replying to the code sample that used to be in the parent comment, not anything in the article.]
Re: React v15.5.0
#48Big news seems to be removal of `React.createClass()` in favor of: class HelloWorld extends React.Component { }
Mild rant:
I'm not convinced ES6 classes are better than components created the old way.
First, the lack of autobinding callback functions for child props is not ideal. I don't even have to think about it with createClass, and it requires at least one extra step with ES6. It's less convenient.
Second, I don't think HOCs are necessarily easier to reason about than mixins in many situations. React is already quite deficient in its own testing utilities (esp. when it comes to functional stateless components and HOCs such that I'd recommend everyone use enzyme), and testing a multi-wrapped HOC can be a PITA whereas whereas a component with multiple mixins is simpler to reason about in comparison. What I care about is testing the output of a component; I don't want to have to understand the internal structure of a component in order to test it in a shallow manner.
Id love to see an argument as to why they are better, but I haven't seen anything convincing. Plus our app uses a ton of non-invasive mixins and the upgrade away from them would complicate the app and make testing way more complicated.
Re: React v15.5.0
#49This is a big deal to deprecate `createClass` and `propTypes`. PropTypes' deprecation is not difficult to handle, but the removal of createClass means one of two things for library maintainers: (1). They'll depend on the `create-class` shim package, or, (2). They must now depend on an entire babel toolchain to ensure that their classes can run in ES5 environments, which is the de-facto environment that npm modules ex…
you know...if it can be transpiled by babel that means you could write it in es5 compatible syntax...yourself...so if you don't want to use the babel tool chain...what's stopping you? Don't know es5? IMO it's not too fun compared to es6...but...
Re: React v15.5.0
#50For those still using propTypes, I'd recommend to take a look at Flow as replacement. https://flow.org/en/docs/frameworks/react
Flow is not a replacement for propTypes, they are complementary. Flow for compile-time errors, propTypes for runtime errors.
For those who want the best of both worlds: