@twobirds/microcomponents 0.0.12 → 0.0.15

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.
Files changed (37) hide show
  1. package/README.md +28 -44
  2. package/assets/documentation/ajaxian-1.png +0 -0
  3. package/assets/documentation/ajaxian-2.png +0 -0
  4. package/assets/documentation/ajaxian-3.png +0 -0
  5. package/assets/documentation/history.md +436 -0
  6. package/assets/documentation/how_tos.md +0 -0
  7. package/assets/documentation/introduction.md +0 -0
  8. package/{microcomponents_magic.md → assets/documentation/magic.md} +1 -1
  9. package/assets/documentation/rnd0023-1.jpg +0 -0
  10. package/assets/documentation/rnd0023-2.jpg +0 -0
  11. package/assets/documentation/rnd0023-3.jpg +0 -0
  12. package/assets/documentation/tB_react.md +204 -0
  13. package/package.json +2 -2
  14. package/public/documentation/ajaxian-1.png +0 -0
  15. package/public/documentation/ajaxian-2.png +0 -0
  16. package/public/documentation/ajaxian-3.png +0 -0
  17. package/public/documentation/functional_requirements.md +8 -0
  18. package/public/documentation/history.md +436 -0
  19. package/public/documentation/how_tos.md +0 -0
  20. package/public/documentation/introduction.md +0 -0
  21. package/public/documentation/magic.md +87 -0
  22. package/public/documentation/proposal_draft.md +37 -0
  23. package/public/documentation/rnd0023-1.jpg +0 -0
  24. package/public/documentation/rnd0023-2.jpg +0 -0
  25. package/public/documentation/rnd0023-3.jpg +0 -0
  26. package/public/documentation/tB_react.md +233 -0
  27. package/public/documentation/usage.md +142 -0
  28. package/public/documentation/why.md +25 -0
  29. package/public/test.js +20 -18
  30. package/src/test.js +22 -20
  31. package/dist/test.d.ts +0 -36
  32. package/dist/test.d.ts.map +0 -1
  33. package/dist/test.js +0 -214
  34. /package/{microcomponents_functional_requirements.md → assets/documentation/functional_requirements.md} +0 -0
  35. /package/{MicroComponentProposal_draft.md → assets/documentation/proposal_draft.md} +0 -0
  36. /package/{microcomponents_usage.md → assets/documentation/usage.md} +0 -0
  37. /package/{microcomponents_why.md → assets/documentation/why.md} +0 -0
@@ -0,0 +1,87 @@
1
+ # Additional concepts: how to make the magic happen...
2
+
3
+ **Micro Components** can literally be anything you can put into an object as a property.
4
+
5
+ Here are some examples of what **Micro Components** can really archieve.
6
+
7
+
8
+ ## The MC() class can be used as a selector of its own, even if you dont attach a micro component yourself
9
+
10
+ Since MC is a class you instanciate with a target element as your selection root element, and you can do this:
11
+
12
+ ```javascript
13
+ const myElement = document.getElementById('myDiv');
14
+
15
+ // find the nearst MC parent elements to this HTMLElement
16
+ const myParent = ( new MC( myElement ) ).parent();
17
+ ```
18
+
19
+ ## Since MC() is a class, you can extend your own micro components with it and have the selectors nicely available
20
+
21
+ Here is some typical usage:
22
+
23
+ ```javascript
24
+ class MyMicroComponent extends MC {
25
+
26
+ constructor( target ){
27
+ super(target);
28
+ }
29
+
30
+ showParents(){
31
+ console.log( this.parents() ); // Logs all anchestor micro components
32
+ }
33
+ }
34
+
35
+ let myDiv = document.querySelector('div');
36
+
37
+ MC.add( myDiv, 'my_micro_component', new MyMicroComponent( myDiv ) );
38
+
39
+ // TADA!
40
+ myDiv
41
+ ._mc
42
+ .my_micro_component
43
+ .showParents();
44
+ ```
45
+
46
+ As you can see, without any effort you have a **second structural layer that hovers over the DOM**.
47
+
48
+ The browser knows nothing of this, except that there may be _mc properties on some HTMLElements.
49
+
50
+ It doesnt get more standard compliant than that.
51
+
52
+
53
+ ## Things I already did with this, in my own framework twoBirds, or in apps that I developed with it:
54
+
55
+ - `encapsulated and modular 3D rendering` in an HTMLElement viewport.
56
+ - `Data Driven Workflow` with micro components using tB specific observables.
57
+ - `DOM handling` in general, lots of `UI functionality`
58
+ - `2 way Data Binding` between forms and observable objects representing the form data
59
+ - `1 way Data Binding` from data observables to the DOM
60
+ - `Loose Coupling` via my own event objects
61
+ - `Rule Engines`
62
+ - `Complex Runtime Templating` without JSX or virtual DOM
63
+ - `Single Page Applications`
64
+ - `Micro Frontends`
65
+ - `Electron Apps`
66
+ - `Progressive Web Apps`
67
+ - `Complex Native Web Components`, that comprised of a set of modular `UI` and `business logic` micro components
68
+ - this ran on the `server` also, in standalone linux nodeJs processes. I removed this some time ago because I didnt want server and client code in one library. Now its easy to make a server variant of the micro component code if required.
69
+
70
+
71
+ Funny stuff:
72
+
73
+ - `Vending Machine Frontends`
74
+ - some `Simulators`
75
+ - `UI for ocean going container ships`
76
+
77
+
78
+ Not from me, but somehow based on my ideas:
79
+
80
+ - `SpaceX` uses web components as an interface in their `Dragon Capsule`. I kind of regard myself to be a co-inventor of web components, since I announced my idea on ajaxian.com in 2007. Anyway, much later the [User defined built in elements](https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_custom_elements#customized_built-in_elements) were a copy of what I already had then. So in a way, this already goes to space.
81
+
82
+
83
+
84
+ This list is far from complete, I used this as a core principle for 20 years. All of the above is modular, so you can use it together.
85
+
86
+
87
+ **Whatever functionality you can do with Javascript, you can encapsule it in a micro component and reuse in any framework that allows for DOM access**.
@@ -0,0 +1,37 @@
1
+ ### RFC Proposal to WHATWG
2
+
3
+ **Title:** Proposal for a **Micro Component Interface** in the DOM
4
+
5
+ **Abstract:**
6
+
7
+ This proposal introduces a standardized interface for managing micro components within HTML elements, enhancing modularity and reusability in web development.
8
+
9
+ **Introduction:**
10
+
11
+ Microcomponents provide a way to encapsulate functionality and state within a target DOM element. This proposal outlines methods for adding, removing, and querying micro components.
12
+
13
+ **Proposed API:**
14
+
15
+ - **Static Methods:**
16
+ - `MC.add( target, key, element)`: Attach a top level micro component to an HTMLElement.
17
+ - `MC.remove( target, key )`: Detach a top level micro component from an HTMLElement.
18
+ - `MC.siblings( target )`: get top level micro components from an HTMLElement.
19
+
20
+ - **Instance Methods:**
21
+ - `add( key, element )`: Attach a private Micro Component to a Micro Component.
22
+ - `remove( key )`: Detach a private Micro Component from a Micro Component.
23
+ - `siblings(search?)`: Retrieve sibling micro components.
24
+ - `parent(search?)`: Get parent top level micro components.
25
+ - `parents(search?)`: Get all ancestor top level micro components.
26
+ - `children(search?)`: Retrieve child top level micro components.
27
+ - `descendants(search?)`: Get all descendant top level micro components.
28
+
29
+ **Use Cases:**
30
+ 1. Modular web applications.
31
+ 2. Enhancing component-based architecture.
32
+
33
+ **Conclusion:**
34
+ Implementing this interface will streamline microcomponent management, fostering cleaner code and improved performance.
35
+
36
+ **References:**
37
+ - [Microcomponents Repository](https://gitlab.com/twoBirds/microcomponents) for a polyfill implementation and usage examples.
@@ -0,0 +1,233 @@
1
+ # Discussing React Prop Drilling with ChatGPT
2
+
3
+ This is an interesting read where I wanted ChatGPT to come up with a Micro Component solution for a React problem.
4
+
5
+ To be honest, I knew MCs can solve it. But I wanted to know what ChatGPT can make of it. Spoiler: it got remarkably close on the first try. The second try was spot on.
6
+
7
+ Please mind I have a trained session with a backlog. So you wont get the same answers.
8
+
9
+ ***( Cut outs and comments are in parentheses...)***
10
+
11
+
12
+ ## Disclaimer:
13
+
14
+ The answers partly reflect on the twoBirds framework instead of Micro Components. twoBirds converts all props into convenience observables automatically, which MCs don't do.
15
+
16
+ The code ChatGPT generated first isn't quite right therefore. Also since I am not a react specialist I cannot guarantee for that part. In general, this is close enough though.
17
+
18
+ I edited the code to reflect the right solution and annotated my changes.
19
+
20
+ I put that into the first answer and asked ChatGPT again.
21
+
22
+ The second answer was spot on, assuming some magic for the convenience observables.
23
+
24
+ Bonus: during this process I got the inspiration that there should be several kinds of state objects:
25
+
26
+ - readonlyState: exports some inner props to the DOM for others to read, but the external state cannot be modified. Not observable.
27
+ - observableState: observable readonlyState. You can attach callbacks that fire on changes.
28
+ - writeableState: observableState that you can modify, typesafe at runtime. Inner methods will do further work probably.
29
+ - hardenedState: writableState (typesafe) that also does sanity checks before inner processing and throws on check failure.
30
+
31
+ This will be a complete public state model in the DOM.
32
+
33
+ And since it is needed for the solution below, that will be the first reference implementation using Micro Components. I hope the React world will be happy.
34
+
35
+ Working with AI can be wonderful...
36
+
37
+ ## Start Session
38
+
39
+ Me:
40
+ **Do you remember our chat regarding Micro Components vs. existing frameworks?**
41
+
42
+ ChatGPT:
43
+
44
+ Yes, I remember our discussion! We talked about your approach to microcomponents as distinct from established frameworks, with a focus on smaller, modular, data-driven components that are stored in a hash attached to DOM elements (specifically in a _tb property in twoBirds or _mc for microcomponents). Your system emphasizes manual wiring, observability, and ease of interaction across components, making it different from React, Vue, or other component libraries that depend heavily on virtual DOMs, JSX, or hooks.
45
+
46
+ Your components follow principles of separation of concerns and DRY by keeping interactions modular but flexible, and they use observables to trigger functions in other components, which can be linked in chains. Your approach allows a component-based design that integrates deeply into the DOM without the overhead of larger frameworks. And while existing frameworks typically follow a top-down data flow, your system allows bi-directional, observable properties that automatically update the DOM when data changes.
47
+
48
+ Would you like to revisit any specific aspect, or compare further?
49
+
50
+
51
+ ## React
52
+
53
+ Me:
54
+ **There was something about React specifically?**
55
+
56
+
57
+ ChatGPT:
58
+
59
+ (...)
60
+
61
+ ### Manual Wiring vs. React’s Context and Hooks:
62
+ React uses Context and hooks (like useState and useEffect) to manage data flow and lifecycle.
63
+
64
+ Your approach leans on manual wiring for connecting data across microcomponents, avoiding the abstraction of hooks and allowing direct, observable-driven updates. This can make the flow of data more transparent and easier to trace in complex applications, whereas hooks can sometimes add complexity or obscurity when trying to understand data dependencies.
65
+
66
+ ### Component Reusability and Scaling:
67
+ Both React and twoBirds support component-based architecture.
68
+
69
+ However, twoBirds allows multiple microcomponents on a single DOM element, and each microcomponent is responsible for specific tasks, making scaling in large applications more modular and straightforward. React encourages separation at the component level, whereas twoBirds does so at the microcomponent level, with direct chaining possible between components.
70
+
71
+ (...)
72
+
73
+ Each of these aspects underlines twoBirds’ focus on minimalism, modularity, and developer control. These are different from React's abstraction and tooling-heavy approach, making your framework potentially more transparent and lightweight for specific use cases.
74
+
75
+ Would you like to dive into any of these differences in more detail?
76
+
77
+
78
+ ## Prop Drilling
79
+
80
+ Me:
81
+ **In general there was a problem regarding carrying properties from a component close to the root of the document to a component that is much deeper into the DOM tree, do you remember that?**
82
+
83
+ ChatGPT:
84
+
85
+ Yes, I remember!
86
+
87
+ We discussed the challenges in carrying properties or state from a root-level component down to deeply nested components. In React, this kind of deep property sharing can become cumbersome and often requires additional tools or patterns, such as:
88
+
89
+ ### Prop Drilling:
90
+ React requires passing data through each level of components in the tree via props, a process known as prop drilling. This can lead to complex and hard-to-manage code, especially when the data isn’t relevant to every component in the chain.
91
+
92
+ (...)
93
+
94
+ In contrast, your twoBirds microcomponents have an alternative approach that makes it easier to pass properties throughout the DOM tree:
95
+
96
+ ### Direct Microcomponent Selectors:
97
+ twoBirds includes selector methods (like .parents() and .descendants()) that allow components to access any microcomponent within the tree without explicit data passing. This capability enables deeply nested components to retrieve properties from higher-level components directly, bypassing the need to route data through intermediary components.
98
+
99
+ ### Observables for State Propagation:
100
+ Since twoBirds uses observables, properties from a root component can be shared across components by observing changes directly. When the observable changes, all relevant components are notified and updated automatically. This is a natural data propagation method that doesn’t require explicit context or external state management.
101
+
102
+ ***( ...this part was wrong, as it reflected on tB convenience observables, instead of pure micro components ... )***
103
+
104
+ ### Manual Wiring for Control:
105
+
106
+ **Because twoBirds relies on manual wiring, you can set up specific connections between components as needed.** This gives you fine-grained control over where and how data flows through the app without involving a top-level state or intermediary components, making it more scalable for larger apps without the need for a Context API or state library.
107
+
108
+ (...)
109
+
110
+ This structure offers a highly flexible, context-free solution for deep property sharing, making it an efficient alternative to prop drilling or global state libraries in many scenarios. Would you like more details on how twoBirds selectors work with observables to achieve this?
111
+
112
+
113
+ ## Generate Code
114
+
115
+ Me:
116
+ **Can you give an example of 2 react components that interact with each other using micro components? Give me the code of both components, using microomponents to exchange data**
117
+
118
+ ***( it took some further hinting, but in the end ChatGPT came up with this: )***
119
+
120
+
121
+ ChatGPT:
122
+
123
+ Here's the updated code:
124
+ Parent Micro Component
125
+
126
+ This component will receive a target DOM node and set a value that propagates down to its descendants:
127
+
128
+ ```javascript
129
+
130
+ // Parent Micro Component
131
+ class ParentMC extends MC {
132
+ constructor(targetNode) {
133
+ super(targetNode); // Receive and pass the target DOM node to the MC constructor
134
+ }
135
+
136
+ set value(newValue) {
137
+ // Send value to all descendants named "targetMC"
138
+ this.descendants("targetMC").forEach(descendant => descendant.data = newValue);
139
+ }
140
+ }
141
+ ```
142
+
143
+ Child Micro Component
144
+
145
+ This component has a data setter that updates the internal React state in each child:
146
+
147
+ ```javascript
148
+
149
+ // Child Micro Component
150
+ class ChildMC extends MC {
151
+ constructor(targetNode, setReactState) {
152
+ super(targetNode); // Receive the target DOM node to be managed by MC
153
+ this.setReactState = setReactState;
154
+ }
155
+
156
+ set data(newValue) {
157
+ this.setReactState(newValue); // Update React state when data is set
158
+ }
159
+ }
160
+ ```
161
+
162
+ React Components Using Micro Components
163
+
164
+ The following React setup attaches ParentMC and ChildMC to their respective DOM elements, using the parent DOM node to instantiate the micro components.
165
+ Parent Component
166
+
167
+ The parent component attaches an instance of ParentMC to the DOM node and sets its value based on inputValue.
168
+
169
+ ```javascript
170
+
171
+ import React, { useState, useRef, useEffect } from 'react';
172
+ import { MC } from '@twobirds/microcomponents';
173
+
174
+ const ParentComponent = () => {
175
+ const [inputValue, setInputValue] = useState("");
176
+ const parentRef = useRef(null);
177
+
178
+ useEffect(() => {
179
+ const parentMC = new ParentMC(parentRef.current); // Pass the DOM node to ParentMC
180
+ MC.add(parentRef.current, 'parentMC', parentMC);
181
+
182
+ // Update value in ParentMC whenever inputValue changes
183
+ parentMC.value = inputValue;
184
+ }, [inputValue]);
185
+
186
+ return (
187
+ <div ref={parentRef}>
188
+ <input
189
+ type="text"
190
+ value={inputValue}
191
+ onChange={(e) => setInputValue(e.target.value)}
192
+ placeholder="Type to send data to children"
193
+ />
194
+ <ChildComponent />
195
+ </div>
196
+ );
197
+ };
198
+ ```
199
+
200
+ Child Component
201
+
202
+ The child component attaches an instance of ChildMC, which updates its state whenever data is set.
203
+
204
+ ```javascript
205
+
206
+ const ChildComponent = () => {
207
+ const [childData, setChildData] = useState("");
208
+ const childRef = useRef(null);
209
+
210
+ useEffect(() => {
211
+ const childMC = new ChildMC(childRef.current, setChildData); // Pass DOM node and state setter to ChildMC
212
+ MC.add(childRef.current, 'targetMC', childMC);
213
+ }, []);
214
+
215
+ return (
216
+ <div ref={childRef}>
217
+ <h3>Received Data:</h3>
218
+ <p>{childData}</p>
219
+ </div>
220
+ );
221
+ };
222
+ ```
223
+
224
+ ***( ... I cannot tell about the react part, but the micro coomponent code is spot on. Like WLAN on the DOM :-) )***
225
+
226
+
227
+ **ChatGPT can produce errors. Check the information.**
228
+
229
+ ## ... yes I do :-)
230
+
231
+ ***( ... but it was right on the money in the end. I love AI, albeit with a healthy grain of sceptic salt. )***
232
+
233
+ ***( ... and I asked about MCs and Angular likewise, and it directly pointed me to a NG module problem that can also be solved. It even came up with sample code. )***
@@ -0,0 +1,142 @@
1
+ # Micro Component Management
2
+
3
+ This system allows you to attach, manage, and interact with micro components.
4
+
5
+ **Micro Components** can literally be anything you can put into an object as a property.
6
+
7
+ Also it has selectors to find micro components in the DOM. It consists of a single class `MC`.
8
+
9
+ ## Summary of MC() Methods
10
+
11
+ - **Static Methods:**
12
+ - `MC.add( target, key, element)`: Attach a top level micro component to an HTMLElement.
13
+ - `MC.remove( target, key )`: Detach a top level micro component from an HTMLElement.
14
+ - `MC.siblings( target )`: get top level micro components from an HTMLElement.
15
+
16
+ - **Instance Methods:**
17
+ - `add( key, element )`: Attach a private Micro Component to a Micro Component.
18
+ - `remove( key )`: Detach a private Micro Component from a Micro Component.
19
+ - `siblings(search?)`: Retrieve sibling micro components.
20
+ - `parent(search?)`: Get parent top level micro components.
21
+ - `parents(search?)`: Get all ancestor top level micro components.
22
+ - `children(search?)`: Retrieve child top level micro components.
23
+ - `descendants(search?)`: Get all descendant top level micro components.
24
+
25
+ **Micro Components** will most likely be **class instances** that expose inner methods **or an observable collection** for data driven workflows, e.g. business process logic.
26
+
27
+ ## Typical Workflow
28
+
29
+ 1. **Attach micro components** to elements using `MC.add()`.
30
+ 2. **Access** micro components by their property key or navigating through DOM (e.g., `siblings()`, `parents()`, `children()`, etc.) **and use their inner functionality**.
31
+ 3. **Manipulate** micro components by adding or removing them as needed or change their properties/call their methods.
32
+
33
+
34
+ ## Hints
35
+
36
+ - **All static methods handle top level Micro Components. These are PUBLIC, that is they are visible in the DOM elements _mc property and usually have an interface.**
37
+
38
+ - **All MC instance methods handle inner Micro Components. These are PRIVATE, that is they are not visible in the DOM elements _mc property.**
39
+
40
+ - **Micro Components can recursively contain Micro Components. Just like npm and the node_modules directory.**
41
+
42
+
43
+ ## Attaching a top level Micro Component to a DOM element
44
+
45
+ To attach a micro component to an HTML element, use the `MC.add()` static function.
46
+
47
+ ### Example Usage:
48
+ ```javascript
49
+ const myElement = document.getElementById('myDiv');
50
+
51
+ // Attach a micro component (most often a class instance, here a simple object for simplicity) with a specific key
52
+ MC.add( myElement, 'myComponent', { name: 'Mike' } );
53
+ ```
54
+
55
+ - After you added a micro component using this function, the HTMLElement will contain a property `_mc` which is a MC() class instance that offers some methods.
56
+ - Also the HTMLElement then has an attribute _mc which will indicate that at least one micro component is attached to this dom element.
57
+
58
+ ## Removing a top level Micro Component from a DOM element
59
+
60
+ Micro components can be removed using the `MC.remove()` static method.
61
+
62
+ ### Removing a Micro component:
63
+ ```javascript
64
+ MC.remove( myDomElement, 'myComponent');
65
+ ```
66
+
67
+ **When all micro components are removed** (the _mc object has no more properties), the `_mc` **attribute is also removed** from the HTML element. The `_mc` **property persists**.
68
+
69
+
70
+ ## Retrieve all top level Micro Components from a DOM element
71
+
72
+ The `MC.siblings()` method retrieves all top level micro components attached to the same DOM element.
73
+
74
+ ### Example:
75
+ ```javascript
76
+ const target = document.querySelector( 'div' );
77
+ const siblings = MC.siblings( target );
78
+ console.log(siblings); // Logs an array of top level sibling micro components
79
+ ```
80
+
81
+ To retrieve a specific micro component by its key:
82
+ ```javascript
83
+ const target = document.querySelector( 'div' );
84
+ const siblings = MC.siblings( target, 'myOtherComponent' );
85
+ console.log(siblings); // Logs an array containing a top level sibling micro component, if its key matches the search string
86
+ ```
87
+
88
+
89
+ ## Retrieving Sibling Micro components
90
+
91
+ The `.siblings()` method retrieves all micro components attached to the same DOM element.
92
+
93
+ ### Example:
94
+ ```javascript
95
+ const siblings = myElement._mc.siblings();
96
+ console.log(siblings); // Logs an array of sibling micro components
97
+ ```
98
+
99
+ To retrieve a specific micro component by its key:
100
+ ```javascript
101
+ const specificSibling = myElement._mc.siblings('anotherComponent');
102
+ ```
103
+
104
+
105
+ - **The following methods hop over HTMLElements that contain no micro component.**
106
+
107
+
108
+ ## 4. Navigating Parent and Ancestor Micro components
109
+
110
+ The `_mc.parent()` and `_mc.parents()` methods allow you to retrieve micro components attached to parent elements.
111
+
112
+ ### Example:
113
+ ```javascript
114
+ const parentMc = myElement._mc.parent();
115
+ console.log(parentMc); // Logs micro components closest nachestor that has microcomponents
116
+
117
+ const allAncestorsMc = myElement._mc.parents();
118
+ console.log(allAncestorsMc); // Logs all ancestor micro components up to document
119
+ ```
120
+
121
+ To retrieve a specific micro component attached to the parent or ancestors:
122
+ ```javascript
123
+ const specificAncestorMc = myElement._mc.parents('myComponent');
124
+ ```
125
+
126
+ ## 5. Retrieving Child and Descendant Micro components
127
+
128
+ The `_mc.children()` and `_mc.descendants()` methods retrieve micro components attached to child elements or any descendants.
129
+
130
+ ### Example:
131
+ ```javascript
132
+ const childMicro components = myElement._mc.children();
133
+ console.log(childMicro components); // Logs an array of nearest child micro components
134
+
135
+ const descendantMicro components = myElement._mc.descendants();
136
+ console.log(descendantMicro components); // Logs micro components attached to all descendants
137
+ ```
138
+
139
+ To search for a specific micro component by key:
140
+ ```javascript
141
+ const specificMc = myElement._mc.<someComponent>;
142
+ ```
@@ -0,0 +1,25 @@
1
+
2
+ ## Why would I give this a try?
3
+
4
+ It is lightweight, proven and can yield positive results immediatly.
5
+
6
+
7
+ ### **As the CTO**:
8
+
9
+ - **Reusability**: this works with every Javascript framework that allows for DOM access, and it will work as long as the DOM exists in browsers. That is, forever.
10
+ - **Scalability**: scales perfectly by design.
11
+ - **Interoperability**: where many teams in different projects should share specific business or UI logic, you want to have something that works in any JS framework you use.
12
+
13
+ ### **As a Project Manager**:
14
+
15
+ - **Separation of Concerns**: since this is a modular approach you can **split UI logic from Business logic** and let diffent teams work on each.
16
+ - using this, you can **work with external developers without the need to give them access to your projects code repository**.
17
+ - you will find out that this allows your project to **become independent from the "tools hell"**. You tend to use **DIY** modules where you had tools before.
18
+
19
+ ### **As a Javascript Developer**:
20
+
21
+ - The learning curve to use this is more than shallow. 1 hour should be enough.
22
+ - This is based on **plain Javascript/Typescript, HTML and CSS**. There is no abstraction layer.
23
+ - From the very start **it is fun to work with**. You are back in control of your code without bigger frameworks, but you are able to interact with them.
24
+ - You can **work for any customer right away**. **No training on their system required**, just fulfill their micro component requirements.
25
+ - Over time, you can **build your own framework or functional libraries** from scratch.
package/public/test.js CHANGED
@@ -143,14 +143,16 @@ class MC {
143
143
  return getMicroComponents([...myDomElements], search);
144
144
  }
145
145
  }
146
- // create test page
147
- document.body.innerHTML = `<div class="level_1"><span><div class="level_2"><span><div class="level_3"><span><div class="level_4"><span><div class="level_5"></div></span></div></span></div></span></div></span></div>`;
148
- let elements = [...document.querySelectorAll("div")].reverse();
149
- elements.forEach((e) => (e.innerHTML = e.innerHTML.repeat(5)));
150
- document.body.innerHTML = document.body.innerHTML.repeat(5);
151
- document.body.innerHTML =
152
- document.body.innerHTML +
153
- "<span>F12 opens the debugger, console has some manual tests...</span>";
146
+ // create test page if necessary, otherwise test what is present
147
+ if (window.location.hostname.indexOf("gitlab") > -1) {
148
+ document.body.innerHTML = `<div class="level_1"><span><div class="level_2"><span><div class="level_3"><span><div class="level_4"><span><div class="level_5"></div><div class="level_5"></div><div class="level_5"></div><div class="level_5"></div><div class="level_5"></div></span></div></span></div></span></div></span></div>`;
149
+ let elements = [...document.querySelectorAll("div")].reverse();
150
+ elements.forEach((e) => (e.innerHTML = e.innerHTML.repeat(5)));
151
+ document.body.innerHTML = document.body.innerHTML.repeat(5);
152
+ document.body.innerHTML =
153
+ document.body.innerHTML +
154
+ "<span>F12 opens the debugger, console has some manual tests...</span>";
155
+ }
154
156
  // create an inner micro component class
155
157
  class MyInnerMC extends MC {
156
158
  constructor(target) {
@@ -178,9 +180,9 @@ class MyMC extends MC {
178
180
  }
179
181
  console.time("MC creation time");
180
182
  // get some element from the DOM
181
- const element = document.querySelector("div");
183
+ const domElement = document.querySelector("div");
182
184
  // Add the custom micro component instance to the target element
183
- let topLevelMC = MC.add(element, "myFirstMC", new MyMC(element));
185
+ MC.add(domElement, "myFirstMC", new MyMC(domElement));
184
186
  // Add the custom micro component instance to every div
185
187
  document.querySelectorAll("div").forEach((e) => {
186
188
  MC.add(e, "myPublicMC1", new MyMC(e));
@@ -189,20 +191,20 @@ document.querySelectorAll("div").forEach((e) => {
189
191
  console.timeEnd("MC creation time");
190
192
  let c = document.querySelectorAll("[_mc]");
191
193
  console.info("number of DOM nodes:", document.querySelectorAll("*").length, "\nnumber of DOM nodes containing micro components:", c.length, "\nnumber of top level micro components:", c.length * 2 + 1, // TODO write reducer
192
- "\nnumber of top level & inner micro components:", c.length * 3 + 2 // TODO write reducer
194
+ "\nnumber of top level & inner micro components:", c.length * 6 + 2 // TODO write reducer
193
195
  );
194
- console.log("ROOT element", element);
195
- console.log("-> ._mc", element._mc);
196
- console.log("-> _mc.myMC", element._mc.myMC);
197
- console.log("-> _mc.myFirstMC._mc (MC.debug = false)", element._mc.myFirstMC._mc);
196
+ console.warn("domElement = first DIV element:", domElement);
197
+ console.log("domElement\n ._mc", domElement._mc);
198
+ console.log("domElement\n ._mc\n .myFirstMC", domElement._mc.myFirstMC);
199
+ console.log("domElement\n ._mc\n .myFirstMC\n ._mc (MC.debug = false)", domElement._mc.myFirstMC._mc);
198
200
  MC.debug = true;
199
- console.log("-> _mc.myFirstMC._mc (MC.debug = true)", element._mc.myFirstMC._mc);
201
+ console.log("domElement\n ._mc\n .myFirstMC\n ._mc (MC.debug = true)", domElement._mc.myFirstMC._mc);
200
202
  MC.debug = false;
201
203
  /*
202
204
  test selectors
203
205
  */
204
206
  let sc = c[2]._mc.myPublicMC1; // 3rd level DIV micro component
205
- console.info("sc", sc);
207
+ console.warn("sc = some div in the middle of the tree, level 3 of 5", sc);
206
208
  console.log("number of sc parents (expect 5)", sc.parents());
207
209
  console.log("number of sc parent (expect 2)", sc.parent());
208
210
  console.log("sc PUBLIC siblings (expect 2)", sc.target.className, Object.keys(sc.target._mc), sc.target._mc);
@@ -211,4 +213,4 @@ MC.debug = true;
211
213
  console.log("sc PRIVATE siblings (MC.debug = true, expect 1)", Object.keys(sc._mc).length, sc._mc);
212
214
  MC.debug = false;
213
215
  console.log("number of sc children (expect 10)", sc.children());
214
- console.log("number of sc descendants (expect 60)", sc.descendants());
216
+ console.log("number of sc descendants (expect 260)", sc.descendants());