https://github.com/bahrus/be-assembling
https://github.com/bahrus/be-assembling
Last synced: 4 months ago
JSON representation
- Host: GitHub
- URL: https://github.com/bahrus/be-assembling
- Owner: bahrus
- License: mit
- Created: 2022-04-15T14:08:14.000Z (about 3 years ago)
- Default Branch: baseline
- Last Pushed: 2022-08-04T06:53:26.000Z (almost 3 years ago)
- Last Synced: 2024-12-31T23:11:50.590Z (6 months ago)
- Size: 7.81 KB
- Stars: 0
- Watchers: 2
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# be-assembling [TODO]
```html
This is my template
This is some slot
```
...yields...
```html
This is my template
This is some slot
```
Why?
As one moves from the micro, "primitive" JS-centric web components to the macro, HTML dominated web components, we are faced with dilemmas as far as how to pass in dependencies that go in quite deep.
Parts don't support nesting [actually, maybe they do...](https://www.abeautifulsite.net/posts/css-parts-inspired-by-bem/#elements-%E2%86%92-subparts). A "web assembly" may contain a deeply nested structure. For example, deeply buried in the markup, there might be a grid, but we want to expose ots configuration, like the columns to the end user.
So one solution is to design these macro web components using ideas loosely modeled after dependency injection:
Define a flat list of all the templates containing html snippets that is essentially the configuration of the macro web component.
Using templates via slots, allow consumers of the web component to override the default templates provided above.
Now given this flat list of templates (some default, some user overrides), the be-assembling decorator kicks into action and weaves the templates together in order to achieve the true markup .
## Example
Consider this example of markup, that takes a JSON array, and slices the columns into a tree like structure, which then links in with a flat grid display (think windows explorer for a nice analogy of the UI).
The markup for this web component could start out looking something like the following:
```html
.
button.expander{
display:none;
}
button[data-children].expander{
display:inline;
}
First NameLast Name
span{
color:green;
}
div[slot="row"]{
display:flex;
flex-direction: row;
justify-content: space-between;
}
```
But now the consumer of the web component may want to add some fields to the form, allowing for filtering / searching of the url to retrieve the JSON data.
The consumer might want to switch the order of the first_name and last_name columns, add additional columns, etc.
Defining a hierarchical structure of the light children is one approach. But this component (together with be-born, be-transplanted) supports an alternative:
Make the markup look as follows:
```html
{
"rowTransform": {
"div": [{}, {}, {"data-path": "path", "style": "marginStyle"}],
"label": "name",
"expanderParts": [true, {"if": "open"}, ["-"], ["+"]],
"button": [{}, {}, {"data-children": "hasChildren"}]
}
}
.
button.expander{
display:none;
}
button[data-children].expander{
display:inline;
}
First NameLast Name
span{
color:green;
}
div[slot="row"]{
display:flex;
flex-direction: row;
justify-content: space-between;
}
```
So the slots essentially become very short-lived virtual "custom elements" that are replaced with the slotted content during the "assembling."
Assembling doesn't start until every slot change has been triggered / and/or node assigned.