...
To keep the original function running, this stage of optimization remains the old mock scheme, so the /assets/json folder is still used to hold all mock data. Under this structure, if developers want to develop locally, they have to modify all the routes in service.ts to include local json file. For example, if the developer wants to develop Home module locally, he has to change the online code to local code.
code.....
| Code Block | ||
|---|---|---|
| ||
├── e2e
├── src
│ ├── app
│ │ ├── core
│ │ │ ├── models
│ │ │ └── services
│ │ ├── shared
│ │ │ ├── components # container of all general components
│ │ │ └── utils # container of all general functions
│ │ ├── views # container of all business pages
│ │ │ ├── alarm
│ │ │ └── ......
│ │ ├── app-routing.module.ts
│ │ ├── app.component.css
│ │ ├── app.component.less
│ │ ├── app.component.html
│ │ ├── app.component.ts
│ ├── assets
│ │ ├── json # container of mock data assets
│ │ ├── i18n # container of internationalization assets
│ │ └── images
│ ├── environments
│ ├── favicon.ico
│ ├── index.html
│ ├── style.css
│ ├── style.less
│ ├── my-theme.css
│ ├── my-theme.less
│ ├── main.ts
│ ├── polyfill.ts
│ ├── test.ts
│ ├── tsconfig.app.json
│ ├── tsconfig.spec.json
│ ├── typing.d.ts
├── .angular-cli.json
├── CHANGELOG.md # recorder of all the important changes
├── karma.conf.js
├── localproxy.conf.json # config for mock server proxy
├── proxy.conf.json # config for server proxy
├── tsconfig.json
├── package.json
└── README.md |
And once he has finished the local development and been ready to push the code online, he has to revert previous changes in service.ts.
To avoid mistakes, we used to maintain two set of code, the local one and the online one. The local code is used for local development and the online code is used for online code contribution. Every time the developer finishes local coding, he has to compare the two set of codes, modify the online code and push it online.
2. Optimization Reason
Based on the previous chapter, the optimization reasons are obvious. The current development method makes the developers maintain two set of codes which brings big problems.
Firstly, the developers have to copy and paste codes repetitively which slows down the development speed, as well as increases the rate of code error caused by copy mistakes and omission. Secondly, each time the developers change mock data, they have to change the service module which is the core part of the project. This method increases the risk of fatal mistakes. Thirdly, it is not a graceful way that ‘unrelated’ codes take part in the mock ‘codes’.
For these reasons, building a new mock data scheme is undoubtedly necessary.
3. Optimization Goals
To solve the problems of current mock data scheme, the new one has to achieve the following goals:
Build the ‘one command start’ system to start the project in mock environment and abandon the previous method that uses two set of codes to mock data
Separate the business codes and the mock data codes to make the mock data module an independent one, which can avoid the negative effects of the project core service
Build a real ‘frontend-backend separation’ system. Meanwhile, this new system should be available for the current mock data files as well as be adapted to the requirement of quick development under the condition of server data not ready.
4. Chosen Tools
json-server+faker.js
json-server is used for build local server and faker.js is used for generating mock data. Click the following links to see more:
json-server:
https://github.com/typicode/json-server
faker.js:
https://github.com/marak/Faker.js/
https://www.npmjs.com/package/faker