-
Notifications
You must be signed in to change notification settings - Fork 0
Angular 5
This will be the first version for this repo to have a core base project and migrate & refactor along the way with angular versions.
As material UI is optional in Angular 5 here is the version used:
So far repo should look like: π»
βββ main
βββ v5xx_Angular_Base_Project
βββ releases
βββ v5xx_Angular_Base_Project
βββ develop
βββ v5xx_Angular_Base_Project
βββ features
βββ v5xx_Angular_Universal_SSR
βββ v5xx_PWA_Service_Worker
In this particular version we are going to explore: Progressive WEB Apps & Service Workers π π» This feature serves as an example and will not be merged along the core project neither maintained.
Link to feature
FGA
βββ app
βββ feature1
βββ [+] sub-feature
βββ [+] shared
βββ feature1.component.ts|html|css|spec.ts
βββ feature1-routing.module.ts
βββ feature1.module.ts
βββ feature2
βββ feature2.component.ts|html|css|spec.ts
βββ feature2-routing.module.ts
βββ feature2.module.ts
βββ core
βββ [+] authentication
βββ [+] footer
βββ [+] guards
βββ [+] http
βββ [+] interceptors
βββ [+] mocks
βββ [+] services
βββ [+] header
βββ core.module.ts
βββ ensureModuleLoadedOnceGuard.ts
βββ logger.service.ts
βββ shared
βββ [+] components
βββ [+] directives
βββ [+] pipes
βββ [+] model
βββ[+] configs
βββ assets
βββ scss
βββ [+] partials
βββ _base.scss
βββ styles.scss
Angular define opinionated project structure in its style guide.
https://v5.angular.io/guide/styleguide#overall-structural-guidelines
- Rule of one: 1 single component, service, etc. per file - easier to read, maintain, and avoid collisions with teams in source control.
- Separation of concerns: separate components, services, etc. in single file - easier to maintain and scale.
- Small functions: small functions are easier to read, test, maintain and reuse.
- Keep files ts|html|css|spec in the same folder to easily locate them.
Do structure the app such that you can Locate code quickly, Identify the code at a glance, keep the Flattest structure you can, and Try to be DRY
- Locate: maintain descriptive and clear folder structure and file to work efficiently.
- Identify: name files to instantly know its content.
- Flat: create folder only if a new one is required for readability.
- Try-DRY: Don't Repeat Yourself but don't sacrifice readability.
- App Module: Every app requires at least one root NgModule. Should import the Core module (only once!)
- Core: Container core application services singletons and component structure navigation (header/footer/etc.)
- Shared: Do declare all components, directives, and pipes in the SharedModule. Do export all symbols from the SharedModule that other feature modules need to use. Beware they are not singleton use. Import the SharedModule into any module where you need to use shared modules or components. Beware the bigger the shared module the bigger the imports.
- Feature: The LIFT guidelines are all covered.
- Lazy loaded feature: The folder makes it easy to identify and isolate the feature content, with its own routing, module and components. Beware directly importing and using a module will load it immediately when the intention is to load it on demand.
Service workers augment the traditional web deployment model and empower applications to deliver a user experience with the reliability and performance on par with natively-installed code. Adding a service worker to an Angular application is one of the steps for turning an application into a Progressive Web App (also known as a PWA).
At its simplest, a service worker is a script that runs in the web browser and manages caching for an application.
The Angular service worker's behavior follows that design goal:
- Caching an application is like installing a native application. The application is cached as one unit, and all files update together.
- A running application continues to run with the same version of all files. It does not suddenly start receiving cached files from a newer version, which are likely incompatible.
- When users refresh the application, they see the latest fully cached version. New tabs load the latest cached code.
- Updates happen in the background, relatively quickly after changes are published. The previous version of the application is served until an update is installed and ready.
- The service worker conserves bandwidth when possible. Resources are only downloaded if they've changed.
To support these behaviors, the Angular service worker loads a manifest file from the server. The manifest describes the resources to cache and includes hashes of every file's contents.
In order for service workers to be registered, the application must be accessed over HTTPS, not HTTP. Browsers ignore service workers on pages that are served over an insecure connection. The reason is that service workers are quite powerful, so extra care needs to be taken to ensure the service worker script has not been tampered with.
ng add @angular/pwa --project *project-name* ng build http-server -p 8080 -c-1 dist/
To try the service worker, use the dev tool and simulate an internet shortage with the offline option. See the file ngsw-config.json for the file cached. As "Build artifacts (JS and CSS bundles)" are cached by default you should still be able to see content. Requests of course would fail to update content retrieved from the server.
Beware even if you update the server and redeploy, you need to forcely refresh the page to query the update. The Angular service worker is doing its job and serving the version of the application that it has installed, even though there is an update available. In the interest of speed, the service worker doesn't wait to check for updates before it serves the application that it has cached.
If you look at the http-server logs, you can see the service worker requesting ngsw.json. This is how the service worker checks for updates.
See ServiceWorkerModule to check or pilot updates.