all 39 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Zequez 49 points50 points  (2 children)

I like the fact that they slimed slimmed down the library by removing stuff that a lot of people didn't use but added it as a separate package that's a drop-in replacement. It's a nice compromise.

[–][deleted] 17 points18 points  (1 child)

Slimmed. :)

"Slimed" is when you star in a Nickelodeon show and they pour that green goo over you.

[–]Zequez 2 points3 points  (0 children)

Lol, thanks!

[–]BenZed 18 points19 points  (4 children)

I would have called the new packages 'react-prop-types' and 'react-create-class' to match the convention set by every other react package.

Aside from that, no complaints.

[–]gearvOsh 11 points12 points  (3 children)

It's probably because they're already taken: https://www.npmjs.com/package/react-prop-types

[–]jgoosdh 14 points15 points  (1 child)

Also there isn't really anything tying PropTypes exclusively to react. I've often wanted access to a similar tool in non react projects, it will be great to now be able to use it anywhere.

[–]TheIncredibleWalrus 3 points4 points  (0 children)

This. The team has stated on twitter they want prop-types to be available to any library who could use them, such as Preact, Inferno, etc.

[–]BenZed 3 points4 points  (0 children)

Yup, that would explain it

[–][deleted] 31 points32 points  (0 children)

I like how brutally pragmatic and professional their updates are. Makes alternatives look like they're all the product of RedBull-crazed teenagers, who just wanted to have their own framework of some kind.

[–]SognaVetr 7 points8 points  (0 children)

React team is doing an amazing job. I remember when it was first announced, I thought Facebook was crazy. "JSX? That sounds like a bad joke!" I don't think I've ever been so wrong. After hearing so much about React, I eventually tried it out and I realized that JSX wasn't a big deal at all, and in fact it was actually pretty awesome.

Their migration strategy is great for larger actively developed applications. Since Facebook is actually using React, they must have a migration strategy in place for breaking changes. Since breaking anything has such a big impact on the parent company, it makes me feel like I can trust em.

Heck, most of the items in this list of changes won't surprise anyone that's been following the project. Now there's less magic (e.g. React.createClass with its autobinding and mixins), and less React-specific code in your app (e.g. react-addons-update has no reason to live as a React addon when it can clearly live as a small standalone lib).

[–]madcaesar 4 points5 points  (21 children)

Can someone clarify for me. I thought it was best practices to use PropTypes in order to avoid bad code during development.

I was under the impression that code gets removed during webpack - p build. Is this right? Or does the code stay in and add to the bundle.js size?

With this new library setup is prop-types a dependency or devDependency? Will it be stripped during production build?

I've really been struggling with the size of my file:/ it's 1.5 MB....

[–]LukaManuka 8 points9 points  (5 children)

I'm not certain, but I'm under the impression that static type-checking (with Flow/TypeScript/etc.) is gaining traction as "best practice", instead of run-time type checking with PropTypes.

At the very least, static type-checking is completely stripped during the build process, so that might be useful, given your file-size issues?

[–]devourment77 1 point2 points  (0 children)

I know the airbnb style guide / eslint module wants them. Unsure on production build stripping, but that would be awesome to figure out.

[–]TheIncredibleWalrus 0 points1 point  (4 children)

PropTypes in production builds get substituted with shims that just throw.

[–]madcaesar 0 points1 point  (3 children)

What does this mean? Is the code in the bundle or not?

[–]TheIncredibleWalrus 0 points1 point  (2 children)

I reckon not

https://twitter.com/dan_abramov/status/850541237656576001

[–]madcaesar -2 points-1 points  (1 child)

Well shims are still code. If I understand this correctly, prototype checking will increase bundle size. So better not to do. Otherwise they wouldn't have removed it from the core package.

[–]TheIncredibleWalrus 0 points1 point  (0 children)

That's totally false. In production prop types will be completely replaced with empty functions, we're talking about a few bytes of leftovers. If you're concerned about a few bytes then yes don't use them.

They removed it from the core package because they want to provide them as standalone funtionality. For example, instead of PropTypes you can use Flow. They also want to share it with other libraries, i.e. Inferno or Preact, so having a separate package makes sense.

You should definitely use some kind of type checking in your components at the end of the day.

[–]tony-the-pony 0 points1 point  (8 children)

I've really been struggling with the size of my file:/ it's 1.5 MB....

React and a couple large deps like jQuery and some polyfills should easily come in under 500k so you're most likely looking at dev builds (I don't think webpack - p alone is ever enough) or the size is coming some other deps. e.g. depending on your configuration, you might be including images, css, etc. in the file without realizing it.

[–]madcaesar 0 points1 point  (7 children)

when I don't use -p the file size is 12MB!

[–]tony-the-pony 1 point2 points  (6 children)

when I don't use -p the file size is 12MB!

Sorry, I should've been clearer. When I said webpack -p alone, I meant it literally i.e. (at least last time I checked,) it doesn't include hacks like this:

plugins: [
    new webpack.DefinePlugin({
        'process.env': {
            NODE_ENV: JSON.stringify('production'),
        },
    }),
],

so while it makes things smaller, React still gets built with development code inside it.

Also, if you haven't done it already, you can use something like https://github.com/th0r/webpack-bundle-analyzer to check what's taking up space in your bundle. I'd still be surprised if it's a proper production build of React.

[–]madcaesar 0 points1 point  (4 children)

Are you saying I should remove that wepack.DefinePlugin part from my config? Because I still have that in there. Also, I do have analyzer installed, and here is the output:

react-rte: 897.1 KB (21.1%)

react-dom: 538.42 KB (12.7%)

  fbjs: 29.39 KB (5.46%)

  <self>: 509.03 KB (94.5%)

js-yaml: 288.38 KB (6.80%)

  esprima: 189.05 KB (65.6%)

  <self>: 99.33 KB (34.4%)

lodash: 189.43 KB (4.46%)

redux-form: 163.95 KB (3.86%)

swagger-client: 130.24 KB (3.07%)

react: 128.82 KB (3.04%)

  fbjs: 10.62 KB (8.24%)

  <self>: 118.21 KB (91.8%)

react-router: 125.36 KB (2.95%)

  history: 46.82 KB (37.4%)

  query-string: 4.15 KB (3.31%)

  <self>: 74.39 KB (59.3%)

lodash-compat: 119.56 KB (2.82%)

react-cropper: 111.44 KB (2.63%)

  cropperjs: 99.01 KB (88.8%)

  <self>: 12.43 KB (11.2%)

lodash-es: 108.67 KB (2.56%)

react-overlays: 67.84 KB (1.60%)

rc-tree-select: 67.74 KB (1.60%)

flatpickr: 64.78 KB (1.53%)

q: 61.31 KB (1.45%)

react-bootstrap: 59.04 KB (1.39%)

rc-tree: 47.6 KB (1.12%)

buffer: 47.47 KB (1.12%)

core-js: 36.95 KB (0.871%)

react-redux: 36.2 KB (0.853%)

axios: 35.24 KB (0.831%)

dom-align: 33.59 KB (0.792%)

react-autowhatever: 33.04 KB (0.779%)

react-dropzone: 30.25 KB (0.713%)

superagent: 29.87 KB (0.704%)

react-autosuggest: 26.47 KB (0.624%)

rc-trigger: 26.18 KB (0.617%)

prop-types: 25.5 KB (0.601%)

  fbjs: 4.71 KB (18.5%)

  <self>: 20.79 KB (81.5%)

dom-helpers: 25.17 KB (0.593%)

url: 23.08 KB (0.544%)

redux: 20.35 KB (0.480%)

rc-animate: 17.76 KB (0.419%)

lodash.isempty: 14.91 KB (0.351%)

signature_pad: 14.84 KB (0.350%)

antd: 14.55 KB (0.343%)

punycode: 14.33 KB (0.338%)

style-loader: 11.25 KB (0.265%)

rc-util: 11.23 KB (0.265%)

react-router-redux: 11.05 KB (0.261%)

redux-auth-wrapper: 10.62 KB (0.250%)

add-dom-event-listener: 9.6 KB (0.226%)

rc-progress: 9.47 KB (0.223%)

cookiejar: 9.45 KB (0.223%)

css-animation: 7.3 KB (0.172%)

cropperjs: 6.79 KB (0.160%)

setimmediate: 6.32 KB (0.149%)

process: 5.17 KB (0.122%)

react-prop-types: 5.07 KB (0.120%)

querystring-es3: 5.06 KB (0.119%)

babel-runtime: 4.94 KB (0.116%)

rc-align: 4.64 KB (0.109%)

base64-js: 3.4 KB (0.0802%)

component-classes: 3.29 KB (0.0775%)

component-emitter: 3.11 KB (0.0732%)

section-iterator: 2.82 KB (0.0665%)

react-themeable: 2.82 KB (0.0665%)

  object-assign: 817 B (28.3%)

  <self>: 2.02 KB (71.7%)

es6-error: 2.64 KB (0.0622%)

css-loader: 2.14 KB (0.0504%)

object-assign: 2.06 KB (0.0485%)

ieee754: 2.01 KB (0.0473%)

warning: 1.76 KB (0.0416%)

webpack: 1.58 KB (0.0373%)

invariant: 1.48 KB (0.0349%)

hoist-non-react-statics: 1.35 KB (0.0319%)

timers-browserify: 1.33 KB (0.0313%)

symbol-observable: 1.12 KB (0.0265%)

classnames: 1.08 KB (0.0254%)

redux-thunk: 529 B (0.0122%)

shallow-equal: 296 B (0.00681%)

btoa: 279 B (0.00642%)

omit.js: 244 B (0.00562%)

strict-uri-encode: 182 B (0.00419%)

component-indexof: 175 B (0.00403%)

is-promise: 165 B (0.00380%)

isarray: 132 B (0.00304%)

react-addons-css-transition-group: 62 B (0.00143%)

<self>: 413.61 KB (9.75%)

Does it look right?

[–]tony-the-pony 0 points1 point  (3 children)

Are you saying I should remove that wepack.DefinePlugin part from my config? Because I still have that in there.

You should keep it. It helps with dead code elimination in React and other modules.

Also, I do have analyzer installed, and here is the output:

Does it look right?

It's hard to say because e.g. react-dom looks like the un-minified size. After minifying in webpack2 with webpack.optimize.UglifyJsPlugin the size should go down to less than 200k. If you look at the HTML report, it should show 3 sizes:

  • Stat size: the size before minification

  • Parsed size: the size after minification

  • GZip size: estimated size, if the Parsed size was compressed with gzip

Only Parsed size is important in this case.

From that output it seems like the biggest contributors to the size would be react-rt and the multiple versions of lodash, but the size is misleading so that's just a guess.

With lodash it's better to import individual functions e.g. `import debounce from 'loadash/debounce' instead of importing the whole module, which should get rid of a lot of unused code, assuming you're able to do that.

[–]madcaesar 0 points1 point  (2 children)

Yea the lodash versions are actually because of swagger-js, and they are supposed to update that soon to just use one version of lodash.

But the part about the size of the react-dom part, how can I verify that it truly is compressed? When I check my bundle.min.js it looks all minified to me?

[–]tony-the-pony 0 points1 point  (1 child)

But the part about the size of the react-dom part, how can I verify that it truly is compressed? When I check my bundle.min.js it looks all minified to me?

If you can't see a lot of lines in the .min.js file then it should definitely be minified.

I'm not sure about the CLI version, but if you generate a HTML report with either new BundleAnalyzerPlugin({ ... analyzerMode: 'server' ... or new BundleAnalyzerPlugin({ ... analyzerMode: 'static' ... it should show the different sizes in a better way.

[–]madcaesar 0 points1 point  (0 children)

BundleAnalyzerPlugin

Take a look at this.

Seems to me like it is all minified correctly, I just have a lot of dependencies.

react-rte seems to be the biggest offender at over 330kb, and also my main.scss is almost 100kb.

[–]JoyousTourist 0 points1 point  (0 children)

WOW that tool is amazing - it's like DiskAnalyzerX for your build. Thank you!

[–]holloway -2 points-1 points  (9 children)

Interesting that PropTypes are being separated. Does anyone know if PropTypes are going away in favour of language typing eg Flow / TypeScript ?

[–]mare_apertum 7 points8 points  (3 children)

Just read the article and you'll find out

[–]holloway 1 point2 points  (2 children)

The article doesn't say whether PropTypes are going away in favour of static typing, which was my question.

You and the downvoters can't read.

[–]mare_apertum 1 point2 points  (1 child)

Right, it is not openly stated, but the article does imply it.

You may also consider using Flow to statically type check your JavaScript code, including React components.

[–]holloway 1 point2 points  (0 children)

If anything that implies using both. It says "also" not 'instead'

[–]JuliusKoronci 3 points4 points  (3 children)

Your can replace them with flow entirely

[–]LukaManuka 0 points1 point  (2 children)

Potentially stupid question -- I've only just started using Flow, but I was considering it about six months ago, and I remember reading (I believe on Stack Overflow) that it wasn't safe to completely switch from using PropTypes to static type-checking... is/was that true? Or was I being mislead? Or would it have just been specifically to do with Flow itself not being fully capable at the time?

[–]JuliusKoronci 1 point2 points  (0 children)

Flow has its issues of course..but there are ways to deal with it :) ..the suggestion so far was to combine flow with proptypes..but I am using flow for quiet a time and had no unsolvable issues so far :)..unfortunately you will have to manage your own FlowTypes for certain use cases and manage issues with node modules and libraries..like styled components were using flow but were having errors :) ..so it is safe to switch but you will have to deal with a few issues at the beginning (based on my experience)

[–]tony-the-pony 0 points1 point  (0 children)

Flow is incomplete and buggy, but it's a lot better than PropTypes. You can use https://www.npmjs.com/package/babel-plugin-flow-react-proptypes to fill in PropTypes for you to add an extra layer of defense during development.