-
Notifications
You must be signed in to change notification settings - Fork 0
Web Architecture
The main dependencies for the web are: TypeScript, react v16, react router v4, and redux. If you don't know what any of these are check out the linked docs, they're great.
Additionally, we use nifty tools like moment.js for dates, query-string for handling query strings in service requests, and classnames for conditionally building out classes for HTML elements.
When running the app locally we use webpack v4 for bundling the application, webpack-dev-server for serving it (hot) on localhost:8080, debounce for managing the number of requests a component can make at a given time, and mockserver for mocking out any service requests made by the FE.
We are using commit hooks. Meaning, when you commit the code the eslint and TypeScript build commands will run to make sure the code you wrote isn't broken. You'll thank us later, trust me, but if you like the wild west then you can turn this off by removing the pre-commit block from our package.json file in the root directory.
Lastly, we use the serverless.yml and buildspec.yml files in the root of the application to build out the resources we need, and deploy the code to AWS. We'll cover the details of this later on.
The following is a list of our most important dependencies:
"classnames": "^2.2.6",
"debounce": "^1.2.0",
"moment": "^2.24.0",
"query-string": "^6.5.0",
"react": "^16.8.6",
"react-dom": "^16.8.6",
"react-hot-loader": "^4.8.4",
"react-redux": "^7.0.3",
"react-router-dom": "^5.0.0",
"redux": "^4.0.1",
"redux-actions": "^2.6.5",
"redux-thunk": "^2.3.0",
"typescript": "^3",
"uuid": "^3.3.3",
"webpack": "^4.30.0"
NOTE: To see a list of all our dependencies, check out the
package.jsonfile in the root directory of the web repository.
public/
index.html
manifest.json
server/
mocks/
[paths/to/mocked/services]
index.js
src/
components/
Common/
[component_name]/
index.ts
styles.scss
Form/
[component_name]/
index.ts
styles.scss
Hooks/
Navigation/
Views/
[page_name]/
Container.ts
View.ts
styles.scss
Routes.ts
constants/
mappers/
models/
redux/
[domain_name]/
actions.ts
creator.ts
reducer.ts
services/
setup/
styles/
_global.scss
_mixins.scss
_variables.scss
utils/
index.tsx
serviceWorker.ts
webpack/
webpack.config.base.js
webpack.config.[env].js
serverless.yml
buildspec.yml
I won't go in to how each piece of the application runs. If you need information on that you can read about it on the react, redux, and other dependency pages. However, I would like to take a moment a discuss how the component folder structure is broken down.
The Components folder is where all the React components are stored. It is further split up in to five subfolders: Common, Forms, Hooks, Navigation, and Views. All of these files and folders make up the UX of the application meaning how it looks and how it interacts with users.
The Common folder is used for all reusable components within the application. For instance, the Spinner component.
The Forms folder is used for all reusable form components. For instance, the Input component.
The Hooks folder is used for all React 16 Hooks. These components are used to cause application changes based on state changes. They are highly reusable.
The navigation folder is used for housing a top level component that wraps the entire application. This component will determine whether to show the Header and Footer components, pass a View component through a protected route, or show full page components such as a mask or spinner.
This folder contains the main entry points in to our application. Each view is comprised of a Container and View component, styles, and all view specific components. For instance, the Home View has the following structure:
PlayerRecordList/
RecordMatch/
SeasonSwitcher/
Container.ts
styles.scss
View.ts
As I said above I won't go in to how all these things work together, I'll leave that to the pros, but I would like to inform you on how this application's state management is broken up.
The redux folder is broken up in to different domains. Each domain contains the actions, creator, and reducer needed to manage the global application state.
The service folder contains all the services needed to communicate with our microservice API.
The mappers folder contains modules that will map our service responses to view models.
The three of these folders work together to setup and maintain the state in our application. The flow of state management is as such:
a component will trigger an action creator -> if the action created is a request for data, it will use a service to asynchronously call the api -> the response will then be passed through a mapper, and then emitted in an action's payload -> the reducer will then pick it up, and save it in to the global state
If you want to quickly see a list of commands that you can run for the web code just take a look at the package.json file in the root directory. You'll find all the possible commands under the scripts block.
yarn build
This command will run TypeScript build on the src directory, and output all the files in to a build directory. This command is primarily run to make sure the code isn't broken, and to transpile the code for when you deploy the application to your AWS S3 bucket.
yarn lint
This command will run all linters on the code. This is used to make sure that there are no general JavaScript, TypeScript, and/or React issues in the code. This command is run when committing, and building the code.
yarn start:web
This command will run webpack and webpack-dev-server, using the hot reload functionality, and serve the site on localhost:8080. What that means for you is as you change the code locally you should see the website change at localhost:8080.
Additionally, if you have the redux extension for Chrome (which we recommend) you should be able to see all the state changes and updates since we setup the extension in our code for local and dev environments.
yarn start:server
This command will run the mock server. The server will run on localhost:9001. Any requests made by the website, that are covered by the mockserver code, will be intercepted and handled.
NOTE: You will need to run both
yarn start:webandyarn start:serverin order for the application to run locally.