Skip to content
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

feat(computed-artifact): support arbitrarily many inputs #2705

Merged
merged 3 commits into from
Jul 19, 2017

Conversation

patrickhulce
Copy link
Collaborator

@patrickhulce patrickhulce commented Jul 17, 2017

fixes #2275

opens the door for #2703 to be built on computed artifacts and re-used in other places

Copy link
Member

@brendankenny brendankenny left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looking good

* Asserts that the length of the array is the same as the number of inputs the class expects
* @param {!Array<*>} artifacts
*/
_assertCorrectNumberOfArtifacts(artifacts) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Arity testing feels like overkill here. It seems like any error would be caught as arity errors usually are in JS (the derived class's compute_() would throw). It also rules out optional arguments, which I believe the cache setup in this PR should handle transparently (absent this check)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

optional arguments won't work because it relies on artifacts array being the same length for every call

consider

artifacts.requestMyComputed(1)
artifacts.requestMyComputed(1, 2)

we get a cannot read property has of undefined error because the cache map was created expecting a nesting level of 1 but needed 2, it seems like a reasonable sanity check and keeps the internal structure simple. if a computed artifact wants to have something as optional it can support passing in undefined as the n-th argument instead, but it'll have to be explicitly passed for now

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, yeah, we'd have to move to storing a value and a Map per node, which isn't so bad. IMO requiredNumberOfArtifacts is a code smell (this is a cache, not a type system), but since we don't have any audits that even want to use multiple arguments yet, I'm ok with waiting for a user if you don't want to implement now.

throw new Error(`${className} requires ${expected} artifacts but ${actual} were given`);
}
}

/* eslint-enable no-unused-vars */

/**
* Request a computed artifact, caching the result on the input artifact.
* @param {*} artifact
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

update jsdoc ("on the input artifacts.", @param {...*} artifacts)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done


return computedArtifact.request(obj0, obj1)
.then(result => assert.equal(result, 0))
.then(() => assert.deepEqual(computedArtifact.lastArguments, [obj0, obj1, mockComputed]))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does testing lastArguments add more information? It seems like testing result is sufficient to check that a cached result is being returned.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nothing has been testing that compute actually received the proper arguments, this is a pretty critical thing considering leaving the original line untouched (aside from the variable rename) would have totally borked every computed artifact

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nothing has been testing that compute actually received the proper arguments

well, the computed artifact subclass tests that don't take shortcuts are :)

Anyway, that's fine.

const multiInputArtifact = new MultipleInputArtifact();

return Promise.resolve()
.then(() => singleInputArtifact.request(1))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the file is already using _ for non-mocha ignorable parameters, so should probably match that

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

while we're on this topic, why is that style a lot of places haha? is it the extra character?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

while we're on this topic, why is that style a lot of places haha? is it the extra character?

it predates the use of eslint on lighthouse #8 :)

I think the original conversation was that it's nice to indicate that an argument is passed in but is ignored (borrowed from several other languages) and got stretched to cover even when there are no parameters (presumably because it's one fewer characters).

Mocha does mess with that a bit, though.

@patrickhulce
Copy link
Collaborator Author

@brendankenny PTAL

Copy link
Member

@brendankenny brendankenny left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@brendankenny brendankenny merged commit 4143aac into master Jul 19, 2017
@brendankenny brendankenny deleted the computed_artifact_tuples branch July 19, 2017 21:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

support tuples as computed artifact input
2 participants