Skip to content

Commit

Permalink
Fix typos (#43)
Browse files Browse the repository at this point in the history
  • Loading branch information
Kevin Venkiteswaran committed Feb 3, 2021
1 parent 566aad1 commit 53591a8
Showing 1 changed file with 8 additions and 8 deletions.
16 changes: 8 additions & 8 deletions text/0110-dynamic-components.md
Original file line number Diff line number Diff line change
Expand Up @@ -22,9 +22,9 @@ This RFC introduces a set of principles and invariants required to preserve a re

**Dynamic instantiation**: creation of a new component instance where the underlying component constructor is not known until runtime.

**string-literal dynamic import**: a dynamic import which uses a static string-literal to reference another module. This category of dynamic imports is statically analyzable.
**String-literal dynamic import**: a dynamic import which uses a static string-literal to reference another module. This category of dynamic imports is statically analyzable.

**variable dynamic import**: a dynamic import which uses Javascript to create the component string parameter to pass into the import function.
**Variable dynamic import**: a dynamic import which uses Javascript to create the component string parameter to pass into the import function.

**Code splitting:** Capability to split the code base in multiple bundles, that can be loaded on demand

Expand Down Expand Up @@ -174,9 +174,9 @@ export default class Chatter extends LightningElement {
async connectedCallback() {
if (isPhone) {
dynamicCtor = await import("lwc-chatter-mobile");
this.dynamicCtor = await import("lwc-chatter-mobile");
} else {
dynamicCtor = await import("lwc-chatter-desktop");
this.dynamicCtor = await import("lwc-chatter-desktop");
}
}
}
Expand Down Expand Up @@ -216,7 +216,7 @@ By using **string-lteral dynamic imports** we are making the dependencies **soft

### Guiding Principles

We want to avoid ad-hoc solutions and proprietary non-standard ways to define dynamic imports. We want to build an API that is future proof, whenever more things land into the spec for modules.
We want to avoid ad-hoc solutions and proprietary non-standard ways to define dynamic imports. We want to build an API that is future proof for whenever more things land into the spec for modules.

### General Invariants

Expand Down Expand Up @@ -275,7 +275,7 @@ export default class LazyTest extends LightningElement {
function tmpl($api, $cmp) {
return [$cmp.lazyConstructor != null // falsy for null or undefined
$api.c("lazy-component", $cmp.lazyConstructor)
? $api.c("lazy-component", $cmp.lazyConstructor)
: null
}];
}
Expand All @@ -292,7 +292,7 @@ export default class LazyTest extends LightningElement {
</script>
```

As you can see in bold from the implementation details above we have transformed the *lwc:lazy* directive into a condition, and we have abstracted the dynamic import mechanism into a high order loader call provisioned by the application container (this will be configurable).
As you can see from the implementation details above we have transformed the *lwc:lazy* directive into a condition, and we have abstracted the dynamic import mechanism into a high order loader call provisioned by the application container (this will be configurable).

#### API invariants

Expand All @@ -303,7 +303,7 @@ As you can see in bold from the implementation details above we have transformed
* The attribute bindings must be explicit.
* No dynamic bag will be allowed (ex. *...props* 'a la React')

> Note: The compiler options will allow you to restrict and or use the loader as decribed above.
> Note: The compiler options will allow you to restrict and/or use the loader as decribed above.
```js
// This will work
Expand Down

0 comments on commit 53591a8

Please sign in to comment.