be-hive v0.0.148

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-decorated elements 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 TODO

<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 Untested

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>

API

be-hiviors are registered via function:

register(ifWantsToBe: string, upgrade: string, extTagName: string);

in be-hive/register.js

be-hive then determines which be-hiviors to inherit.

Behivior aspects Untested

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.

For this, we can add a fourth parameter to our register function:

register(ifWantsToBe: string, upgrade: string, extTagName: string, aspects: string[]);

So for the example above, this would look like:

register('intl', 'time', 'be-intl', ['weekday', 'year', 'month', 'day']);