Provide an API for querying BCD data

[ddbeck]

Summary: BCD itself should provide an API for querying data with strings that contain dotted paths and raise useful looking errors for missing or non-existent data.

A common pattern for contributors and consumers of BCD is to use a dotted path to reference features. Some of these features are valid identifiers that can be used with the BCD package. For example, display can be referred to as css.properties.display and the JavaScript code bcd.css.properties.display gets the expected feature data (assuming you've run const bcd = require('mdn-browser-compat-data')).

Other features have names which break this way of accessing data. For example, bcd.css.properties.margin-top doesn't work (you'd have to do bcd.css.properties['margin-top'] instead).

Some BCD consumers have implemented some variation on this function:

function query(someString) {
    let data = someString.split('.').reduce(function(prev, curr) {
        return prev ? prev[curr] : undefined
    }, bcd);
    return data;
}

We should provide a tested and documented query API instead, so consumers can query the data without reinventing this function each time.

[antross]

I'd love to see some reusable query APIs become part of the project!

This may be a bit too much to have in BCD directly, but I wanted to share that we created a higher-level wrapper in webhint for our usage of BCD providing isSupported and getUnsupported helpers. This is somewhat similar to what caniuse-api provides (and was created as part of migrating parts of our code from caniuse to MDN data).

Currently these helpers support querying for HTML and CSS features, including support for matches data. If there's interest, we'd be happy to extract this out into something more broadly usable.

Examples:

// Check if `<details>` is supported in both "chrome 74" and "ie 11"
isSupported({ element: 'details' }, ['chrome 74', 'ie 11']); // returns `false`
getUnsupported({ element: 'details' }, ['chrome 74', 'ie 11']); // returns `['ie 11']`

// Check if the HTML `hidden` attribute is supported in "firefox 65" 
isSupported({ attribute: 'hidden' }, ['firefox 65']); // returns `true`
getUnsupported({ attribute: 'hidden' }, ['firefox 65']); // returns `null`

// Check if CSS alpha hex values are supported
isSupported({ property: 'color', value: '#00FF00FF' }, browsers);

// Check if CSS 3D transforms are supported
getUnsupported({ property: 'transform', value: 'translate3d(0, 0, 10px)' }, browsers);

[Elchi3]

Thanks @antross, this is awesome feedback! 👍 I could imagine us supporting such a querying API as part of this project.

This is somewhat similar to what caniuse-api provides (and was created as part of migrating parts of our code from caniuse to MDN data).

Do you have more insights into this process? Would you mind commenting any findings you had on
#4051?

[antross]

@Elchi3 We didn't run into any new differences in the schemas between the caniuse and browser-compat-data. We did need to include a helper to map browser names from caniuse to browser-compat-data since our browser names originate from browserslist.

Once we had the helper, the conversion itself was fairly easy since we were only using the caniuse data in a few places. Here's the exact commit if you want to take a look: webhintio/hint@e76e864

[queengooborg]

I think that this was resolved when #6585 was, so I'm going to go ahead and close this.