Another rgb pulse revision, fix unit tests, update package version #26
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR does the following:
Rgb
classpulse
methodtest/rgb.collection.js
andtest/rgb.js
filesRgb
classpulse
methodThe update to
pulse
method address the situation whenon()
is called while theRgb
is pulsing. Beforehand, theRgb
would emit RGB values in thetween
state of thepulse
animation. Now theRgb
will emit the RGB values stored byprev
.Screencast video before update:
before.update.-.on.mp4
Screencast video after update:
after.update.-.on.mp4
Testing
The unit tests that tested
Animation.render
intest/rgb.collection.js
were revised sinceAnimation.render
was updated by this PR. Instead ofcolor()
, theupdate
method is called.Three tests broke when
grunt
was run.These tests are now fixed and handful of new tests were added in
test/rgb.js
for thepulse
method in theRgb
class.Follow-up
I posted 3 PRs to mainline johnny-five so that we can hopefully move to using mainline johnny-five in the future.
Add option to round scaled sensor values - PR
Modify Animation temporalTTL so that it is configurable - PR
Adding a pulse method to the RGB class - PR
For the first 2 PRs, the implementations were a bit different from those for the forked code-dot-org/johnny-five in that the customizations were made to be configurable.
In the case that not all Code.org customizations are approved, we could plan to create a johnny-five wrapper so that we can still use mainline johnny-five and not have to maintain a forked project.
Here is a write-up of the costs/benefits of using mainline vs maintaining forked project.
This is the original investigation in moving off the johnny-five fork.