be-hive [WIP]

Inheriting behiviors

be-hive lets it snow in August.

be-hive allows us to manage and coordinate the family, or HTML frimework of be-enhanced custom enhancements.

Without be-hive, the developer is burdened with plopping an instance of each enhancement inside each shadow DOM realm.

With the help of the be-hive component, the developer only has to plop a single instance of be-hive inside the Shadow DOM realm, like so:

<be-hive></be-hive>

This signals that the Shadow DOM realm is opting-in, and allowing element behiviors, and will inherit all the behiviors from the parent Shadow DOM realm, by default.

But the child Shadow DOM realm can develop a personality of its own by:

1. Adding additional behiviors by adding specific be-enhanced based enhancement instructions inside the be-hive instance tag.
2. Avoiding naming conflicts by overriding the attribute associated with the inherited behivior.
3. Preventing inheriting unwanted behiviors from affecting the child Shadow DOM realm.
4. Start over. Only decorator elements manually added inside the Shadow DOM (preferably inside the be-hive tag, for inheritance to work within)

Syntax for customizations of inherited behiviors [WIP]

<be-hive passthrough></be-hive>

allows behiviors to flow though the ShadowDOM realm to child ShadowDOM realms, but skips over the one in question.

<be-hive include=... exclude=...>

allows for blocking or specifying which behiviors to enable within the ShadowDOM realm, while allowing them to flow through to the child ShadowDOM realms, unaffected.

<be-hive overrides='{
    "be-sharing":{
        "becomes": "be-familial"
    },
    "be-gracious": {
        "becomes": "be-respectful"
    },
    "be-disobedient-without-facing-the-consequences": {
        "block": "true"
    }
}'></be-hive>

Be like Sirius Black

If the inherited behiviors are all just too odious to inherit, there's an option to start again:

<be-hive be-severed>
</be-hive>

Adding back a personality trait [TODO]

If one Shadow DOM blocks an inherited behivior, child Shadow DOMs can bring it back within their (and descendent) shadow DOM realms thusly:

<be-hive overrides='{
    "be-disobedient-without-facing-the-consequences": {
        "unblock": "true"
    }
}'></be-hive>

The "Emcee" script files

To make the ceremony of establishing DOM enhancements go as smoothly as possible, be-hive rests on a key object structure that should accompany each enhancement -- the "EMC" object.

EMC stands for "Enhancement Mount Configuration".

These objects are small, and most of it can be turned into a JSON import:

For example:

export const emc: EMC = {
    base: 'be-based',
    map: {
        '0.0': 'base'
    },
    enhPropKey: 'beBased',
    importEnh: async () => {
        const {BeBased} = await import('./behance.js');
        return BeBased;
    }
};

This provides a kind of "entrance ticket" that can then be used to enhance an element programmatically:

const beBasedEnhancement = await oDivElement.beEnhanced.whenResolved(emc);

It also contains all the needed information for how to parse the the behavior/enhancement attributes, into an object that can be passed in to the behavior/enhancement during template instantiation.

To see a more complex example along those lines, see be-switched.

Potentially, an alternative EMC definition can be used inside different Shadow DOM roots in order to avoid clashes between two libraries that use the same names.

So we can synchronously load these small files (or a bundle of such small files), which would block being able to do template instantiation on a first load. but at least the files are as small (and as parsable) as possible.

The thinking is we can take a template filled with lots of inline behavior/enhancement attributes, where that template is going to be cloned repeatedly. In order to avoid excessive string parsing, we can analyze the template:

If the EMC's "cache" setting is set to true, then it will look at the initial attribute settings, and see if it matches something that is already in the cache, and if so, do a (structural clone?) of the object without re-parsing. Maybe this should only be done if the root fragment isn't connected?

Behivior aspects [WIP]

There may be some cases, especially for enhancements with many equally important parameters where a developer may prefer to break up the settings into separate attributes. Here's an example where I can definitely see the appeal. So instead of:

<time lang="ar-EG" datetime=2011-11-18T14:54:39.929Z be-intl='{ "weekday": "long", "year": "numeric", "month": "long", "day": "numeric" }'></time>

we can write:

<time lang="ar-EG" 
    datetime=2011-11-18T14:54:39.929Z 
    be-intl-weekday=long be-intl-year=numeric be-intl-month=long
    be-intl-day=numeric>
</time>

This is especially useful in environments where the consumer of the behivior prefers to use attributes, rather than properties, for updating a property of the behivior.