Budgeting - React + Redux + Webpack (tree shaking) Sample App
Clone or download
ikovic and grgur Use React.lazy instead of react-loadable (#206)
* Set prettier to add trailing commas

* Bumped react version

* Remove react-loadable and use React.lazy instead

* Switch to Terser for minification

* fixed vulnerabilities

* Stacked charts don’t rely on loadable

* more components moved out

* fixed tests
Latest commit 95e67da Nov 7, 2018
Failed to load latest commit information.
.github Update Flow integration (#92) Aug 30, 2017
app Use React.lazy instead of react-loadable (#206) Nov 7, 2018
docs Add flow documentation (#95) Aug 31, 2017
flow-interfaces [WIP] Webpack 4 upgrade (#180) Aug 31, 2018
flow-typed Use React.lazy instead of react-loadable (#206) Nov 7, 2018
jest Update dependencies (#130) Dec 28, 2017
public SPA redirect rules for Netlify (#197) Sep 4, 2018
.babelrc #199 Upgrade to babel v7 (#200) Sep 11, 2018
.browserslistrc Add Autoprefixer (#103) Sep 20, 2017
.codeclimate.yml add ignore config for code climate (#201) Sep 24, 2018
.coveralls.yml Update Flow integration (#92) Aug 30, 2017
.editorconfig [finish #141395439] Mobile support (#31) Mar 9, 2017
.eslintignore Initial flow setup May 18, 2017
.eslintrc [WIP] Webpack 4 upgrade (#180) Aug 31, 2018
.firebaserc firebase deploy Mar 15, 2017
.flowconfig [WIP] Webpack 4 upgrade (#180) Aug 31, 2018
.gitignore [WIP] Webpack 4 upgrade (#180) Aug 31, 2018
.prettierrc Use React.lazy instead of react-loadable (#206) Nov 7, 2018
CONTRIBUTING.md Complete Flow integration (#77) Aug 23, 2017
LICENSE.md [WIP] Webpack 4 upgrade (#180) Aug 31, 2018
Polyfills.md Budget grid (#27) Mar 8, 2017
README.md Fixed code climate URL Sep 4, 2018
circle.yml Circle CI workflow cfg v2 (#191) Sep 4, 2018
firebase.json Update Flow integration (#92) Aug 30, 2017
jest.config.js Update dependencies (#130) Dec 28, 2017
package-lock.json Use React.lazy instead of react-loadable (#206) Nov 7, 2018
package.json Use React.lazy instead of react-loadable (#206) Nov 7, 2018
postcss.config.js Add Autoprefixer (#103) Sep 20, 2017
webpack.config.base.js [WIP] Webpack 4 upgrade (#180) Aug 31, 2018
webpack.config.dev.js PWA support (#190) Sep 3, 2018
webpack.config.dll.js [WIP] Webpack 4 upgrade (#180) Aug 31, 2018
webpack.config.prod.js Use React.lazy instead of react-loadable (#206) Nov 7, 2018


PRs Welcome MIT Licensed FOSSA Status CircleCI Coverage Status Maintainability Powered by Modus_Create

Budgeting :: A Modern React, Redux, React Router 4, Webpack Sample App

React, Redux, Router, Webpack, Sass

Production-ready React + Webpack architecture implemented on consumer web apps of some of the most successful enterprises in the world. Perceived performance and development experience are key factors in this setup. You can use this code base for learning or to scaffold your mission-critical project.

See live demo.

React Budgeting App

Budgeting Application

This is a simple budget management application. It tracks inflow and outflow, shows remaining budget, and interesting reports with charts. As such, it offers more features than the usual Todo App.

Budgeting app is a showcase project that demonstrates important decisions in architecture and development of a modern React application.

Feel free to use it as a reference app or a starter kit.

Key concepts:


Budgeting App Performance The app loads in 1 second on 3G, cache disabled

Budgeting app is blazing fast, thanks to the smart architecture and Webpack 3 configuration. It takes about 1000ms (1s) to load on 3G (see above).

Alex Russel Test Emerging Markets 3G Filmstrip

The aggressive test above shows the budgeting app loads in under 5 seconds. It's a heavily limited connection that accounts for poor connectivity and limited bandwidth.


All important (aka critical path) assets are loaded as early as possible, while the others (e.g. images or GitHub buttons) will load after the first render.

How did we get that performance?

  1. Minimal application core. We decided to ditch the usual convention of creating a vendor chunk. Instead, it's bundled in the app core. The app core is actually very small, containing just the code needed to bootstrap the app.
  2. Common code is a chunk. We let Webpack figure out which bundles we reuse in chunks and create a common chunk that's also asyncronous.
  3. Redux module injection. Each chunk contains respective views and redux modules. Yes, that means reducers, action creators, actions - are all dynamically injected as we navigate through routes. That adds to the minimal application core concept and PRPL pattern.
  4. H2 Push. The app is hosted on Firebase and we use the magic of HTTP2 Push to push some of the scripts before they are requested.
  5. Pre-caching. Service Workers pre-cache resources so the browser can access them as soon as the user needs to.


Charts are developed using the awesome D3 library. The idea behind showing charts is not only to show beautiful content, but also to demonstrate keeping heavy content in a chunk that owns it. In other words - we show how applications can run fast even if they use larger libraries.

D3 is used in the /reports route only. Given that major routes are separate chunks (code splitting FTW!), the entire D3 library is bundled with the code that needs it. That makes the /reports route a bit heavier than the initial /budget route, but it also makes routes much faster to load.

Performance Budgets

We are looking to maintain the lightest possible application core (aka entry chunk). Our target is 300kB for the entrypoint and 300kB for all other assets. This is how we set it in webpack configuration:

performance: {
  maxAssetSize: 300000,
  maxEntrypointSize: 300000,
  hints: 'warning',

Adding lots of extra code to the entry chunk might cause the build (npm run build) process to show a warning.

Performance Budgets

Simulated size warning

Note that running webpack dev server in production mode (npm run prod) will trigger this warning because of the additional dev server code injected in the app. This code will not show in regular production builds.

Service Workers

Service workers are enabled only when serving static files, not through webpack-dev-server. Here's how you can test service worker functionality:

  1. Run npm run build to build the app
  2. Run npm run prod to serve the app on localhost:3000
  3. Run a new instance of Chrome with disabled security (because localhost is not on https):


open -a "Google Chrome" --args --user-data-dir=/tmp/unsafe --unsafely-treat-insecure-origin-as-secure=http://localhost


/path/to/chrome --user-data-dir=/tmp/unsafe --unsafely-treat-insecure-origin-as-secure=http://localhost


chrome.exe --user-data-dir=c:\temp --unsafely-treat-insecure-origin-as-secure=http://localhost
  1. Now you can observe network traffic in the Network tab or SW activity in Application > Service Workers in Developer Tools


The app was built using these aweseome technologies

NPM Scripts

  • npm install - install dependencies
  • npm start - run development server
  • npm run prod - run production server
  • npm run build - build app for deployment
  • npm run serve - serve previously built app using pushstate server
  • npm run lint - lint check
  • npm run lint:fix - lint check + autofixes + prettify code with prettier
  • npm test - run test suite
  • npm run test:fix - run test suite watching files for changes
  • npm run flow - run flow type checking
  • npm run update-types - update flow library definitions

Honorary Mentions

Want more?

This project is maintained by Modus Create. Fantastic React apps are in our DNA so give us a buzz if we can help with your awesome project.



FOSSA Status