Improve heatmap documentation. #859
Conversation
This also removes a utility function that is also handled in a proper utils method.
manthey
force-pushed
the
update-heatmap-docs
branch
from
c6157a5 to
28aeffb
Compare
| * @protected | ||
| * Initialize. | ||
| * | ||
| * @returns {this} | ||
| */ | ||
| this._init = function () { |
There was a problem hiding this comment.
I guess we do not take spec for heatMap? Also, looks like we do not have arg passed here?
There was a problem hiding this comment.
The args are passed when we create the feature. They aren't repassed to _init. It works out the same, but is a different code format from other features.
There was a problem hiding this comment.
I see, so the arg to s_init would be meaningless (not looking at the code right now)
There was a problem hiding this comment.
It will be the arg that was passed when creating the feature, so it is used. It just has a different scope.
There was a problem hiding this comment.
When the feature is instantiated, we call m_this._init(arg);, where arg doesn't get used as passed, since the canvas _init doesn't take it. The canvas's _init then calls s_init with the feature-scoped arg (rather than the function scoped arg).
There was a problem hiding this comment.
I agree that this is inconsistent with other features, but this feature, in general, has some inconsistencies (styles have to be values rather than values or functions, for instance). I was mostly trying to update the documentation in this PR. Other improvements should be separate PRs.
There was a problem hiding this comment.
I see, yes the arg is passed to the feature will be used. Thanks, I understand the original intent. Should we create an issue to make this feature consistent just so that we do not forget it? I am fine with fixing it in some other PR as that work is orthogonal to this PR.
|
Yes. Documenting things is a powerful way to find and fix issues. |
This also removes a utility function that is also handled in a proper utils method.