aqoviaelements / properties-from-ancestor-behavior Goto Github PK

Failing test to follow

Consider allowing:

PropertiesFromAncestorBehavior({
            language: {
                ancestorPropertyAlias: 'lang',
            },
        })

To allow boilerplate-less integration when some 3rd party behaviors that we want to use in our component impose a different attribute name than our ancestors already provide.

One fine example is HTML language specification. Adding this feature would allow PropertiesFromAncestorBehavior to be used to smoothly marry the HTML's blessed lang attribute/property with the Polymer's blessed AppLocalizeBehavior's language property.

(unless Polymer's component changes the property name - PolymerElements/app-localize-behavior#98)

Created the issue as I see @zlamma has created a branch WIP branch for it.

Wanted to comment:

• We need to modify our build process to publish an NPM
• Should we adopt hybrid mode (where possible) to retain v1 compatibility?
• We should update our guidance on creating web components (and maybe move it to a wiki repo, like ASP.NET engineering guidelines) so our policy/guidance is developed in the open.

c.c. @rickyattiliaaq

It was discovered when <custom-datepicker disabled> did not appear disable because its <fieldset> was not disabled.

It's more of a corner case (when you have this feature you're likely to also want to use it), and 'workaroundable' (put the disable on the ancestor), but certainly confusing when happens.

To be demonstrated in test - watch for commits below.

Failing test to follow

The title says it all...
This won't be hard :)

Suggestion:
Allow to mimic the way native HTML control receive the ubiquitous disabled flag from ancestor <fieldset>:

<fieldset disabled>
    <input type="text" name="some-standard-textbox-control" />
    <select id="some-standard-select-control">...</select>
    <my-crazy-form-control1/>
    <my-crazy-form-control2/>
    <button id="some-standard-button-control" type="submit">Submit</button>
</fieldset>

(all the native controls will be disabled - note we did not have to pass any disabled arguments except for the ancestor).

Currently, receving the ancestor's disabled attribute will only work if the fieldset is disabled from the start (so has the disabled attribute).

To allow this to work where the fieldset initially has no such attribute and dynamically react to disabling inside the web controls, we can allow specifying a selector that allows to find the ancestor to bind:

PropertiesFromAncestorBehavior({
            disabled: {
                type: Boolean,
                ancestorMatches: 'fieldset',
            },
        })

and then listen to attribute changes on that ancestor (using MutationObserver) to receive the change to true.

This would make it easier to create components that match succinctness of the native HTML elements.

We currently don't need this feature, so it might not get implemented - please react with 'thumbs up' here to give us feedback that you'd like it.

Since, during reading in descendant, we're already abstracting the fact that the property comes from the ancestor, we might as well not require a leaky abstraction to change the value.

This should be relatively easy to implement in web-component ancestors (which already fire 'my-prop1-changed' events), but will be more tricky for native DOM nodes (need to not fall into recursive call; need to respect the serialization rules using serializeValueToAttribute. Maybe we should also set a property, to save on serialization & subsequent deserialization in children.), but this variant might actually be pretty valuable - it would allow creating elements that are very dynamic, while looking like 'pure static HTML' structure (e.g. no JavaScript security concern or Polymer knowledge needed - just put your global app parameters in attributes of outermost elements and your web components inside just look like HTML).

Not really easy to have such a corner case, but there you go - i realized I made a mistake.

It happens because, when you apply the behavior multiple times, each behavior thinks it can own the Element.__propertiesFromAncestorBehavior.observer property, so it assigns it on initialization.

If this component is to be reused, it better be rock solid.