From 4636461c79235f809f478f485113f6271683343f Mon Sep 17 00:00:00 2001 From: Joshua Comeau Date: Thu, 4 Jan 2018 21:19:47 -0500 Subject: [PATCH] Spelling nits for `code-splitting.md` Really enjoyed the newest code-splitting docs! I caught a minor spelling error: `interuptive` -> `interruptive`. I decided to indulge the writer in myself, and chose to rephrase some things that I thought could be clearer. That said, I recognize that many of the changes I'm making are subjective. More than happy to simply fix the typo, but I thought I'd submit this to see if others agree with my phrasing changes. --- content/docs/code-splitting.md | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/content/docs/code-splitting.md b/content/docs/code-splitting.md index 6472dfdd..bbaffc94 100644 --- a/content/docs/code-splitting.md +++ b/content/docs/code-splitting.md @@ -44,7 +44,7 @@ console.log(add(16, 26)); // 42 > > Your bundles will end up looking a lot different than this. -If you're using [Create React App](https://github.com/facebookincubator/create-react-app), [Next.js](https://github.com/zeit/next.js/), [Gatsby](https://www.gatsbyjs.org/), or a similar tool you will have a Webpack setup out of the box to bundle your +If you're using [Create React App](https://github.com/facebookincubator/create-react-app), [Next.js](https://github.com/zeit/next.js/), [Gatsby](https://www.gatsbyjs.org/), or a similar tool, you will have a Webpack setup out of the box to bundle your app. If you aren't, you'll need to setup bundling yourself. For example, see the @@ -59,17 +59,18 @@ if you are including large third-party libraries. You need to keep an eye on the code you are including in your bundle so that you don't accidentally make it so large that your app takes a long time to load. -But if your app keeps growing, eventually you'll end up with a large bundle. So -it's good to get ahead of the problem and start "splitting" your bundle. -[Code-Splitting](https://webpack.js.org/guides/code-splitting/) is a feature -of bundlers like Webpack and Browserify (via +To avoid winding up with a large bundle, it's good to get ahead of the problem +and start "splitting" your bundle. + [Code-Splitting](https://webpack.js.org/guides/code-splitting/) is a feature +supported by bundlers like Webpack and Browserify (via [factor-bundle](https://github.com/browserify/factor-bundle)) which can create multiple bundles that can be dynamically loaded at runtime. Code-splitting your app can help you "lazy-load" just the things that are currently needed by the user, which can dramatically improve the performance of -your app. Overall you haven't reduced the amount of code in your app, but -you've avoided loading code that the user may never need. +your app. While you haven't reduced the overall amount of code in your app, +you've avoided loading code that the user may never need, and reduced the amount +of code needed during the initial load. ## `import()` @@ -96,7 +97,7 @@ import("./math").then(math => { > > The dynamic `import()` syntax is a ECMAScript (JavaScript) > [proposal](https://github.com/tc39/proposal-dynamic-import) not currently -> accepted into the language standard. It is expected to be accepted within the +> part of the language standard. It is expected to be accepted within the > near future. When Webpack comes across this syntax, it automatically start code-splitting @@ -107,16 +108,16 @@ out of the box in [Next.js](https://github.com/zeit/next.js/#dynamic-import). If you're setting up Webpack yourself, you'll probably want to read Webpack's [guide on code splitting](https://webpack.js.org/guides/code-splitting/). Your Webpack config should look vaguely [like this](https://gist.github.com/gaearon/ca6e803f5c604d37468b0091d9959269). -When using [Babel](http://babeljs.io/) you'll need to make sure that Babel can -parse the dynamic import syntax but is not transforming it. For that you will need [babel-plugin-syntax-dynamic-import](https://yarnpkg.com/en/package/babel-plugin-syntax-dynamic-import). +When using [Babel](http://babeljs.io/), you'll need to make sure that Babel can +parse the dynamic import syntax without transforming it. For that, you will need [babel-plugin-syntax-dynamic-import](https://yarnpkg.com/en/package/babel-plugin-syntax-dynamic-import). ## Libraries ### React Loadable -[React Loadable](https://github.com/thejameskyle/react-loadable) provides you -with a nice API for introducing code splitting into your app wherever you -render a component. +[React Loadable](https://github.com/thejameskyle/react-loadable) wraps +dynamic imports in a nice, React-friendly API for introducing code +splitting into your app at a given component. **Before:** @@ -148,14 +149,13 @@ React Loadable helps you create [error states](https://github.com/thejameskyle/react-loadable#loading-error-states), [timeouts](https://github.com/thejameskyle/react-loadable#timing-out-when-the-loader-is-taking-too-long), [preloading](https://github.com/thejameskyle/react-loadable#preloading), and -more. It can even help you [server-side](https://github.com/thejameskyle/react-loadable#------------server-side-rendering) -render an app with lots of code-splitting. +more. It can even help you [server-side render](https://github.com/thejameskyle/react-loadable#------------server-side-rendering) an app with lots of code-splitting. ## Route-based code splitting Deciding where in your app to introduce code splitting can be a bit tricky. You -want to make sure you choose places that will split bundles evenly, but not be -terribly interuptive to the users of your app. +want to make sure you choose places that will split bundles evenly, but won't +disrupt the user experience. A good place is to start is with routes. Most people on the web are used to page transitions taking some amount of time to load. You also tend to be