- Features
- Requirements
- Getting Started
- Application Structure
- Development
- Routing
- Configuration
- Production
- Deployment
- node
^8
- npm
^3.0.0
- Install app and functions dependencies:
npm i && npm i --prefix functions
- Create
src/config.js
file that looks like so if it does not already exist:const firebase = { // Config from Firebase console } // Overrides for for react-redux-firebase/redux-firestore config export const reduxFirebase = {} export const analyticsTrackingId = '<- Google Analytics Tracking ID ->' export const publicVapidKey = '<- publicVapidKey from Firebase console ->' export default { env, firebase, reduxFirebase, publicVapidKey, analyticsTrackingId }
- Start Development server:
npm start
While developing, you will probably rely mostly on npm start
; however, there are additional scripts at your disposal:
npm run <script> |
Description |
---|---|
start |
Serves your app at localhost:3000 and displays Webpack Dashboard |
start:simple |
Serves your app at localhost:3000 without Webpack Dashboard |
build |
Builds the application to ./dist |
lint |
Lints the project for potential errors |
lint:fix |
Lints the project and fixes all correctable errors |
Husky is used to enable prepush
hook capability. The prepush
script currently runs eslint
, which will keep you from pushing if there is any lint within your code. If you would like to disable this, remove the prepush
script from the package.json
.
There are multiple configuration files:
- Project Path Configuration -
project.config.js
- Firebase Project Configuration (including settings for how
src/config.js
is built on CI) -.firebaserc
- Project Configuration used within source (can change based on environment variables on CI) -
src/config.js
- Cloud Functions Local Configuration -
functions/.runtimeconfig.json
More details in the Application Structure Section
The application structure presented in this boilerplate is fractal, where functionality is grouped primarily by feature rather than file type. Please note, however, that this structure is only meant to serve as a guide, it is by no means prescriptive. That said, it aims to represent generally accepted guidelines and patterns for building scalable applications. If you wish to read more about this pattern, please check out this awesome writeup by Justin Greenberg.
├── build # All build-related configuration
│ ├── scripts # Scripts used within the building process
│ ├── karma.config.js # Test configuration for Karma
│ └── webpack.config.js # Environment-specific configuration files for webpack
├── server # Express application that provides webpack middleware
│ └── main.js # Server application entry point
├── src # Application source code
│ ├── config.js # Environment specific config file with settings from Firebase (created by CI)
│ ├── constants.js # Project constants such as firebase paths and form names
│ ├── index.html # Main HTML page container for app
│ ├── main.js # Application bootstrap and rendering
│ ├── normalize.js # Browser normalization and polyfills
│ ├── components # Global Reusable Presentational Components
│ ├── containers # Global Reusable Container Components (connected to redux state)
│ ├── layouts # Components that dictate major page structure
│ │ └── CoreLayout # Global application layout in which to render routes
│ ├── routes # Main route definitions and async split points
│ │ ├── index.js # Bootstrap main application routes with store
│ │ └── Home # Fractal route
│ │ ├── index.js # Route definitions and async split points
│ │ ├── assets # Assets required to render components
│ │ ├── components # Presentational React Components (state connect and handler logic in enhancers)
│ │ ├── modules # Collections of reducers/constants/actions
│ │ └── routes/** # Fractal sub-routes (** optional)
│ ├── static # Static assets
│ ├── store # Redux-specific pieces
│ │ ├── createStore.js # Create and instrument redux store
│ │ └── reducers.js # Reducer registry and injection
│ ├── styles # Application-wide styles (generally settings)
│ └── utils # General Utilities (used throughout application)
│ │ ├── components.js # Utilities for building/implementing react components (often used in enhancers)
│ │ ├── form.js # For forms (often used in enhancers that use redux-form)
│ │ └── router.js # Utilities for routing such as those that redirect back to home if not logged in
├── project.config.js # Project configuration settings
├── .firebaserc # Firebase Project configuration settings (including ci settings)
└── tests # Unit tests
We use react-router
route definitions (<route>/index.js
) to define units of logic within our application. See the application structure section for more information.
Build code before deployment by running npm run build
. There are multiple options below for types of deployment, if you are unsure, checkout the Firebase section.
- Install Firebase Command Line Tool:
npm i -g firebase-tools
Note: Config for this is located within travis.yml
firebase-ci
has been added to simplify the CI deployment process. All that is required is providing authentication with Firebase:
- Login:
firebase login:ci
to generate an authentication token (will be used to give Travis-CI rights to deploy on your behalf) - Set
FIREBASE_TOKEN
environment variable within Travis-CI environment - Run a build on Travis-CI
If you would like to deploy to different Firebase instances for different branches (i.e. prod
), change ci
settings within .firebaserc
.
For more options on CI settings checkout the firebase-ci docs
- Run
firebase:login
- Initialize project with
firebase init
then answer:
- What file should be used for Database Rules? ->
database.rules.json
- What do you want to use as your public directory? ->
build
- Configure as a single-page app (rewrite all urls to /index.html)? ->
Yes
- What Firebase project do you want to associate as default? -> your Firebase project name
- Build Project:
npm run build
- Confirm Firebase config by running locally:
firebase serve
- Deploy to Firebase (everything including Hosting and Functions):
firebase deploy
NOTE: You can usefirebase serve
to test how your application will work when deployed to Firebase, but make sure you runnpm run build
first.
- Why node
8
instead of a newer version?
Cloud Functions runtime runs on 8
, which is why that is what is used for the travis build version.
- Why
enhancers
overcontainers
? - For many reasons, here are just a few:- separates concerns to have action/business logic move to enhancers (easier for future modularization + optimization)
- components remain "dumb" by only receiving props which makes them more portable
- smaller files which are easier to parse
- functional components can be helpful (along with other tools) when attempting to optimize things