Deploying to gh-pages from @ 2a555fd 🚀

Author: dhmlau

pages/en/lb4/Application-generator.md

@@ -68,7 +68,6 @@ The tool will prompt you for:
 - Optional modules to add to the application. These modules are helpful tools to
   help format, test, and build a LoopBack4 application. Defaults to `true` for
   all of the modules. The prompted modules are:
-
   - [`eslint`](https://www.npmjs.com/package/eslint)
   - [`prettier`](https://www.npmjs.com/package/prettier)
   - [`mocha`](https://www.npmjs.com/package/mocha)

pages/en/lb4/Appsody-LoopBack.md

@@ -904,7 +904,6 @@ terminal window opened in your project directory. In our case, this is the
     ![lb4appsody_template_webpage_cloud_1.png](./imgs/lb4appsody_template_webpage_cloud_1.png)
 
     As mentioned earlier, all these endpoints are available:
-
     - Application endpoint: /
     - API explorer: /explorer
     - Open API Spec: /openapi.json

pages/en/lb4/Binding.md

@@ -532,7 +532,6 @@ reqCtx.scope = BindingScope.REQUEST;
     ```
 
     The owner context for the code snippet above will be:
-
     - 'foo.app': appCtx
     - 'foo.server': serverCtx
 
@@ -560,7 +559,6 @@ reqCtx.scope = BindingScope.REQUEST;
     ancestors recursively
 
     b. Use the scope of binding found to locate the resolution context:
-
     - Use the `current context` for `CONTEXT` and `TRANSIENT` scopes
     - Use the `owner context` for `SINGLETON` scope
     - Use the first context that matches the binding scope in the chain starting

pages/en/lb4/Crafting-LoopBack-4.md

@@ -70,7 +70,6 @@ as:
 
 2.  Technical debt is accumulating, for example inconsistent designs across
     modules and feature flags for different behaviors. Here are a few examples:
-
     - Various modules use different registries to manage different types of
       artifacts, such as remoting metadata, models, datasources, and middleware.
     - Different flavors are used to allow custom logic to intercept
@@ -81,7 +80,6 @@ as:
 
 3.  It is becoming more difficult to add new features or fix bugs as some areas
     start to reach the limit of the current design.
-
     - The `loopback-datasource-juggler` module is a kitchen sink for many
       things, such as typing, data modeling, validation, aggregation,
       persistence, and service integration.
@@ -94,7 +92,6 @@ as:
     make code changes in LoopBack modules. The current version of LoopBack has
     ad-hoc extensibility at various layers. Extension points are not
     consistently defined. For example,
-
     - Use Express to register middleware.
     - Use remoting hooks to intercept remote method invocations.
     - Use CRUD hooks to add logic around CRUD operations.
@@ -149,28 +146,24 @@ generation of API creation platform. For more information, read the blog post
 LoopBack 4's goals are:
 
 1.  Catch up with latest and greatest technology advances.
-
     - Adopt [ES2016/2017](http://exploringjs.com/es2016-es2017/index.html) and
       [TypeScript](https://www.typescriptlang.org/) for ease of maintenance and
       productivity.
     - Embrace new standards such as [OpenAPI Spec](https://www.openapis.org/)
       and [GraphQL](http://graphql.org/).
 
 2.  Promote extensibility to grow the ecosystem.
-
     - Build a minimal core and enable everything else to be implemented via
       extensions.
     - Open the door for more
       [extension points and extensions](https://github.com/loopbackio/loopback-next/issues/512).
 
 3.  Align with cloud native experience for microservices.
-
     - Adopt cloud native microservices by adopting initiatives such as
       [Cloud Native Computing Foundation](https://www.cncf.io/).
     - Make LoopBack a first-class citizen of the microservices ecosystem.
 
 4.  Remove the complexity and inconsistency across modules.
-
     - Use a consistent registry and APIs to manage artifacts and their
       dependencies.
     - Pay down technical debts by refactoring complex modules.
@@ -227,20 +220,16 @@ Here are the stages we are marching through toward the final version of LoopBack
 4 as illustrated below.
 
 1.  **Rebase and rewrite the core**
-
     - Leverage TypeScript for better code quality and productivity.
-
       - Provide optional type system for JavaScript.
       - Provide planned features from future JavaScript editions to current
         JavaScript engines.
 
     - Unify the asynchronous programming model/style.
-
       - 100% promise-based APIs.
       - Async/Await as first-class async programming style.
 
     - Implement an IoC Container for better visibility and extensibility
-
       - Universal registry across different modules
       - Dependency injection as a pattern to manage dependencies
 
@@ -249,11 +238,9 @@ Here are the stages we are marching through toward the final version of LoopBack
       - Component encapsulates a list of extensions as a whole
 
 2.  **Validate the core design by implementing an REST/HTTP invocation chain**
-
     - Add top-down REST API creation which starts with OpenAPI specs.
 
     - Build sequence of actions for inbound http processing
-
       - Introduce sequence as the composition of actions
       - Implement the most critical actions to fulfill the REST API routing and
         invocation
@@ -262,7 +249,6 @@ Here are the stages we are marching through toward the final version of LoopBack
 
       Models are the centerpieces of the current LoopBack applications. . They
       take multiple responsibilities:
-
       - Data modeling
       - Anchor for API related business logic
       - Persistence or service invocation
@@ -272,13 +258,11 @@ Here are the stages we are marching through toward the final version of LoopBack
 
       Implement the core functionality of authentication as a component, which
       includes:
-
       - Decorators to denote authentication requirement
       - `authenticate` action to handle authentication
       - Extension points for various authentication strategies
 
 3.  **Rebuild our integration and composition capabilities**
-
     - Introduce repositories to represent data access patterns such as CRUD or
       Key/Value stores
     - Provide a reference implementation of CRUD and KV flavors of repository
@@ -302,7 +286,6 @@ Here are the stages we are marching through toward the final version of LoopBack
     approach to describe these artifacts by code (apis and decorators), we would
     like to add declarative support so that they can be declared in JSON/YAML
     files.
-
     - Define a new domain-specific language (DSL) in JSON/YAML format and
       corresponding templates.
     - Define the project layout to organize project artifacts.
@@ -314,14 +297,12 @@ Here are the stages we are marching through toward the final version of LoopBack
       boot process can be tailored for both tooling and runtime.
 
 5.  **Tooling (CLI & UI)**
-
     - Add CLI and UI tools to:
       - Scaffold LoopBack 4 applications
       - Manage artifacts such as sequences, actions, controllers, repositories,
         services, datasources and models
 
 6.  **Enable cloud native experience**
-
     - Allow controllers to be exposed as gRPC services
     - Allow interaction with other gRPC services
     - Integration with microservices deployment infrastructure such as Docker
@@ -400,7 +381,6 @@ independent of the nature of such artifacts.
 
 - A consistent registry to provide visibility and addressability for all
   artifacts.
-
   - Visibility: Each artifact has a unique address and can be accessed via a URI
     or key. Artifacts can also be visible at different scopes.
 
@@ -410,13 +390,11 @@ independent of the nature of such artifacts.
     points/extensions decouples providers and consumers.
 
 - Ability to compose with dependency resolution.
-
   - Composability: It's common that one artifact to have dependencies on other
     artifacts. With dependency injection or service locator patterns, the core
     will greatly simplify how multiple artifacts work together.
 
 - A packaging model for extensions.
-
   - Pluggability: Extensions can be organized and contributed as a whole. We
     need to have a packaging model so that extension developers can create their
     own modules as bundles and plug into a LoopBack application.

pages/en/lb4/Customizing-server-configuration.md

@@ -160,12 +160,10 @@ with the base path.
 The router can be configured to enforce `strict` mode as follows:
 
 1. `strict` is true:
-
    - request `/orders` matches route `/orders` but not `/orders/`
    - request `/orders/` matches route `/orders/` but not `/orders`
 
 2. `strict` is false (default)
-
    - request `/orders` matches route `/orders` first and falls back to
      `/orders/`
    - request `/orders/` matches route `/orders/` first and falls back to

pages/en/lb4/DEVELOPING.md

@@ -387,7 +387,6 @@ two groups:
    blocks.
 
    Examples:
-
    - `@loopback/core` is re-exporting all public API provided by
      `@loopback/context`.
 
@@ -778,7 +777,6 @@ The script does the following steps:
 1. Determine the parentDir and package name.
 
    The first argument can be one of the following:
-
    - package-name
    - @loopback/package-name
    - extensions/package-name
@@ -792,7 +790,6 @@ and falls back to `extensions`.
    are skipped.
 
 3. Fix up the project
-
    - Remove unused files
    - Improve `package.json`
 
@@ -935,7 +932,6 @@ configuration, it's important to verify that all usage scenarios keep working.
     ```
 
 5.  Test integration with supported IDEs:
-
     - [Visual Studio Code](./Developing-with-vscode.md#how-to-verify-eslint-setup)
     - [WebStorm](./Developing-with-webstorm.md#how-to-verify-eslint-setup)
 

pages/en/lb4/Developing-with-vscode.md

@@ -81,7 +81,6 @@ can e.g. rename `inject` to test.)
 
 2.  Verify that ESLint extension is not reporting any warnings in the output
     window:
-
     - pres _Cmd+shift+P_ or _Ctrl+shift+P_ to open task selector
     - find and run the task `ESLint: Show Output`
     - check the logs

pages/en/lb4/Extension-generator.md

@@ -55,7 +55,6 @@ The tool will prompt you for:
 - Optional modules to add to the extension. These modules are helpful tools to
   help format, test, and build a LoopBack4 extension. Defaults to `true` for all
   of the modules. The prompted modules are:
-
   - [`eslint`](https://www.npmjs.com/package/eslint)
   - [`prettier`](https://www.npmjs.com/package/prettier)
   - [`mocha`](https://www.npmjs.com/package/mocha)

pages/en/lb4/Getting-started.md

@@ -63,6 +63,7 @@ running the project.
 
 ```sh
 cd getting-started
+npm i
 npm start
 ```
 

pages/en/lb4/Inside-Loopback-Application.md

@@ -28,7 +28,6 @@ Once the API requirements are assessed,
 
 - LoopBack's features can be used to satisfy the requirements from different
   developers:
-
   - Front end designers:
 
     > Can create an `Online Shopping prototype` to try the UI experience by
@@ -74,7 +73,6 @@ mobile application is the same.
 Similar to this we can breakdown further use cases into API requirements.
 
 - `Shopping use cases`
-
   - User starts adding and removing items to the shopping cart.
   - If the user logs out the shopping cart is saved and re-loaded when the user
     logs in next time.