Doc from Main to Prod for v13.3.0

docs/development_suite/monitoring/resources/custom-resources.md

@@ -2,7 +2,7 @@
 id: custom-resources
 title: Monitor your Custom Kubernetes Resources
 sidebar_label: Monitor your Custom Kubernetes Resources
-slug: "/development_suite/monitoring/resources/jobs"
+slug: "/development_suite/monitoring/resources/custom-resources"
 ---
 
 
@@ -12,6 +12,8 @@ If deployed, the information on the [Custom Resources](/console/design-your-proj
 If you created one or more Custom Kubernetes Resource from a marketplace template **prior** to Console release v13.3.0, the resources **will not be visible by default**. 
 
 Please ensure to [update your resource](/marketplace/add_to_marketplace/add_item_by_type/add_custom_resource.md#update-a-custom-resource-to-the-console-v1330) version via [miactl](/cli/miactl/10_overview.md) to one that has the properties `resourceId` and `type` correctly set in the `runtime` object field of its definition, otherwise the Custom Kubernetes Resources won't be visible in the section even if the resource is active.
+
+Furthermore, the resources created **from scratch** will not be visible in the Runtime area. We will introduce the support in future versions of the Console.
 :::
 
 

docs/microfrontend-composer/external-components/bundling.md

@@ -1,13 +1,13 @@
 ---
 id: bundling
-title: Bundling your webcomponents with vite
+title: Bundling your Web Components with vite
 sidebar_label: Bundling
 sidebar_position: 30
 ---
 
-The aim of this section is to highlight some features we found useful to bundle webcomponents together.
+The aim of this section is to highlight some features we found useful to bundle Web Components together.
 
-Let's say we have a bunch of webcomponents such as
+Let's say we have a bunch of Web Components such as
 
 ```text
 ├── my-button
@@ -23,7 +23,7 @@ Let's say we have a bunch of webcomponents such as
 |
 ```
 
-The most important thing to remember is that webcomponent definitions must appear once and they must not repeat themself even accidentally (the bundler might mess up with the tree of dependencies).
+The most important thing to remember is that Web Component definitions must appear once and they must not repeat themself even accidentally (the bundler might mess up with the tree of dependencies).
 
 Another point of attention must be the desired output: whether the library will be consumed by browsers only or could be made available to Node.js environments as development resource, say by publishing an npm library.
 
@@ -109,11 +109,11 @@ export default defineConfig({
 })
 ```
 
-Be aware that runtime loading of webcomponents is a key factor here. The browser `window` won't be able to follow dynamic imports in order to wait page `onload` event, which means that loading multiple webcomponents from different bundles might make them appear at different times. A consistent visualization is instead guaranteed when the components are loaded together, at least to a further degree.
+Be aware that runtime loading of Web Components is a key factor here. The browser `window` won't be able to follow dynamic imports in order to wait page `onload` event, which means that loading multiple Web Components from different bundles might make them appear at different times. A consistent visualization is instead guaranteed when the components are loaded together, at least to a further degree.
 
-This remark does not rule out separate bundles. For instance `micro-lc` is bundled separately with respect to its loading webcomponent, which by default shows spinning hexagons until `micro-lc` fires an `onload` event. `mlc-loading-animation` loads first and is safe to assume won't need `micro-lc` to be loaded to start its work.
+This remark does not rule out separate bundles. For instance `micro-lc` is bundled separately with respect to its loading Web Component, which by default shows spinning hexagons until `micro-lc` fires an `onload` event. `mlc-loading-animation` loads first and is safe to assume won't need `micro-lc` to be loaded to start its work.
 
-A components library providing buttons, tables, forms, is definitively an example of a set of webcomponents which must be bundled together:
+A components library providing buttons, tables, forms, is definitively an example of a set of Web Components which must be bundled together:
 
 1. they load together avoiding weird flashes
 2. they reuse chunks of code like stylesheets

docs/microfrontend-composer/external-components/manifest.md

@@ -1,42 +1,31 @@
 ---
 id: manifest
-title: The Webcomponent Manifest
+title: The Web Component Manifest
 sidebar_label: Manifest
 sidebar_position: 20
 ---
 
-Any webcomponent is or aims to be:
+Any Web Component is or aims to be:
 
 1. an HTML tag
 2. a CSS encapsulated environment
 3. a JS business logic unit
 
-As HTML tag, a custom webcomponent has `attributes` and `properties`. Moreover a pair `attribute` and `property` can be coupled by reflecting changes: a change on the former is mirrored on the latter, and viceversa.
+As HTML tag, a custom Web Component has `attributes` and `properties`. Moreover a pair `attribute` and `property` can be coupled by reflecting changes: a change on the former is mirrored on the latter, and viceversa.
 
 ## Basics
 
-The Configurator layout section queries the webcomponents to discover their properties/attributes using a static getter promise called a _Manifest_.
+The Configurator layout section queries the Web Components to discover their metadata and their properties/attributes using a static getter promise called a _Manifest_.
+
+The `__manifest` static getter must return a JavaScript object containing information on the component metadata, properties and attributes, and API mocks.
 
 :::tip
-You can use the [JSON schema](https://raw.githubusercontent.com/micro-lc/compose-toolkit/main/schemas/manifest.schema.json) to check your components manifests.
+You can use the [JSON schema](https://raw.githubusercontent.com/micro-lc/compose-toolkit/main/schemas/manifest.schema.json) to get information on the supported properties and to check your components manifests.
 :::
 
-The `__manifest` static getter must return a JavaScript object that has a key `type` which must be `object` (to be JSON schema compatible) and a map of `properties`.
-
-```typescript
-const manifest = {
-  type: 'object',
-  properties: {
-    // list of properties
-  }
-}
-```
-
-A custom button might look like:
-
-```typescript
-// my-button.ts
+As an example, consider the following custom button component
 
+```typescript title=my-button.ts
 import { LitElement } from 'lit'
 
 class MyButton extends LitElement {
@@ -48,14 +37,13 @@ class MyButton extends LitElement {
 }
 ```
 
-and thus will instruct the Configurator preview section with the following manifest
+The component exposes the static getter `__manifest` thus instructing the Configurator preview section with the following manifest
 
-```typescript
-// manifest.ts
+```typescript title=manifest.ts
 import type { Manifest } from '@micro-lc/compose-toolkit'
 
 const manifest = {
-  type: 'object',
+  label: 'My awesome button',
   properties: {
     hidden: {
       type: 'boolean'
@@ -66,9 +54,11 @@ const manifest = {
 export default manifest
 ```
 
-In the outlined example, the Configurator layout section will provide its configuration form with a boolean toggle for the `hidden` property.
+## Attribute and properties
+
+The component attributes and properties can be described using the `properties` key of the manifest, which should be an object mapping the component properties to a JSON schema.
 
-Types can be **almost** anything that JSON schema provides:
+Properties types can be **almost** anything that JSON schema provides:
 
 1. `boolean`
 2. `string`
@@ -85,13 +75,11 @@ Complex properties such as objects and arrays are also handled in a `no-code` fa
 
 The most basic visualization for an `object` without a schema is an IDE-like editor, with basic JSON validation capabilities. Likewise an array has a `no-code` item selector, which again, without schema will spawn an IDE-like editor for each one of its items.
 
-The owner/developer of custom webcomponents can enforce `no-code` configurability by nesting the component manifest.
+The owner/developer of custom Web Components can enforce `no-code` configurability by nesting the component manifest.
 
 For instance:
 
-```typescript
-// my-button.ts
-
+```typescript title=my-button.ts
 import { LitElement } from 'lit'
 
 interface Action {
@@ -110,12 +98,10 @@ class MyButton extends LitElement {
 
 can be described by the following manifest
 
-```typescript
-// manifest.ts
+```typescript title=manifest.ts
 import type { Manifest } from '@micro-lc/compose-toolkit'
 
 const manifest: Manifest = {
-  type: 'object',
   properties: {
     action: {
       type: 'object',
@@ -132,17 +118,15 @@ export default manifest
 
 Despite the `action` being an object, the Configurator layout section will spawn a modal (which can have potentially infinite levels of nesting) to configure `type` as a string with at most 2 fixed values and `url` as a string.
 
-## Mia's Configuration Advanced
+### Mia's Configuration Advanced
 
-The Webcomponent manifest is a superset of a compliant draft-07 JSON schema. The Configurator guarantees to display a `no-code` comfortable version of each property.
+The Web Component manifest is a superset of a compliant draft-07 JSON schema. The Configurator guarantees to display a `no-code` comfortable version of each property.
 
-Beside this specification, Configurator can enforce some extra logic using a special property, available to any webcomponent property or nested property: `__mia_configuration`.
+Beside this specification, Configurator can enforce some extra logic using a special property, available to any Web Component property or nested property: `__mia_configuration`.
 
 Let's consider a custom button
 
-```typescript
-// my-button.ts
-
+```typescript title=my-button.ts
 import { LitElement } from 'lit'
 
 class MyButton extends LitElement {
@@ -156,12 +140,10 @@ class MyButton extends LitElement {
 
 with manifest
 
-```typescript
-// manifest.ts
+```typescript title=manifest.ts
 import type { Manifest } from '@micro-lc/compose-toolkit'
 
 const manifest = {
-  type: 'object',
   properties: {
     hidden: {
       type: 'boolean'
@@ -231,16 +213,14 @@ export interface MiaConfiguration {
 }
 ```
 
-### The `oneOfGuard` key
+#### The `oneOfGuard` key
 
 Suppose your property is a JSON `oneOf` an there's a guard key which allows to distinguish non-overlapping types. For instance:
 
-```typescript
-// manifest.ts
+```typescript title=manifest.ts
 import type { Manifest } from '@micro-lc/compose-toolkit'
 
 const manifest = {
-  type: 'object',
   properties: {
     action: {
       type: 'object',
@@ -273,7 +253,7 @@ By using `oneOfGuard` set to `type` Configurator layout section is able to provi
 
 If the user selects `http-post` then 2 string input will appear in order to configure `url` and `payload`, otherwise an IDE-like editor will allow to type directly the `payload` property since no schema was provided.
 
-### The `schema-hint` key
+#### The `schema-hint` key
 
 Configurator provides some types that are well known and often used in order to avoid writing down a repeating JSON schema multiple times.
 
@@ -290,7 +270,7 @@ Configurator provides some types that are well known and often used in order to
    projection, or a Fast Data Single View.
 10. A `micro-lc/applications` is the list of currently configured applications in the Configurator initial section.
 
-### The `shared-key` key
+#### The `shared-key` key
 
 JSON schema supports referencing of property definitions. Despite not being a fixed pattern there's a recommendation for draft-07 which suggests to use the key `definitions` at the first level of your JSON configuration. In the most recent drafts it will be substituted by the `$defs` keyword.