-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add experimental utils #9441
Add experimental utils #9441
Conversation
const { isBrowser, descendantKeys, joinPath } = require('./walkingUtils'); | ||
const query = require('./query'); | ||
|
||
function* lowLevelWalk(data = bcd, path, depth = Infinity) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why two walking generators? walk()
wraps lowLevelWalk()
but only yields __compat: { … }
objects. lowLevelWalk()
is the basis for other sorts of interesting walks, such as walking non-__compat
namespaces or walking browsers, which have not been implemented yet.
}); | ||
it('visits every point in the tree', function () { | ||
const paths = Array.from(lowLevelWalk()).map(step => step.path); | ||
assert.ok(paths.length > 13000); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Strictly speaking, this doesn't really test this function—just that its output is reasonable—but I feel like the tests on walk()
do the heavy lifting here.
); | ||
}); | ||
|
||
it('should yield every feature by default', function () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test (and the similar test of visit
) are rather slow (>300ms and >50ms on my machine), which Mocha highlights. I think it's mostly the overhead of Mocha, but we could restrict this to some subtree if we want to speed things up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could also have a unchanging set of BCD-like JSON files for testing only, which could exercise things that are uncommon in BCD or likely to change over time. That would probably be blazing fast to test with.
One might still have one or two smoke tests involving the real data.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Testing with a unchanging set will be a lot easier now that we've got the consistent data
parameter.
Is this something I should come up with as part of this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've tried using walk('api')
to answer a quick question I had with success.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's do it!!
Last week, I talked with Florian and he suggested that I document the experimental status somewhere. I've done that by adding a README file to the Thank you for the excellent reviewing here, @foolip! |
This PR adds some experimental utilities for traversing compat data. These are not intended to be included in the package and won't (at least for now) constitute a public API.
It's kinda big and it's got some rough edges. I'll do a self-review to highlight a few things.
Related to #6585
Originally from: https://github.com/ddbeck/bcd-utils