@twobirds/microcomponents 0.0.8 → 0.0.9
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +2 -2
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -14,7 +14,7 @@ npm i @mySampleLib/Button;
|
|
|
14
14
|
```
|
|
15
15
|
... on the server side.
|
|
16
16
|
|
|
17
|
-
Imagine
|
|
17
|
+
Imagine your micro components to be organized like a "node_modules" directory that is attached to a DOM node.
|
|
18
18
|
|
|
19
19
|
**On the client side** MCs reside inside DOM nodes in a "_mc" property, or inside each other recursively. Usually they provide a direct interface to their inner code.
|
|
20
20
|
|
|
@@ -30,7 +30,7 @@ This is a massive undertaking. MCs are just the foundation of what I do. I am ab
|
|
|
30
30
|
|
|
31
31
|
By **"Open Source"** I mean **really free and open**, as **you get all my inner source code with it**. Once you understand the Micro Component principle, you are back in command of your software, no matter what MC functionality you import in your system. Since **Micro Components** are encapsuled, off-shoring and near-shoring is no problem, and reusability is guaranteed. Your external coders do not need to access your code repository or your toolchain. They only need to understand MCs.
|
|
32
32
|
|
|
33
|
-
**Established frameworks**,
|
|
33
|
+
**Established frameworks**, as opposed to MCs, **provide a documented interface to a hidden layer of closed source inner functionality**. MCs can be used to **add an interface to components you developed using other frameworks**. So you can still use your existing code, and MCs in it. But you will want to migrate it ASAP, since MCs work with any FW.
|
|
34
34
|
|
|
35
35
|
## General
|
|
36
36
|
|