Enforce stricter types for formatters in MappedMatrixVis
#1703
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.
Follows #1702
As planned, the problem became much simpler: all the typing complexity related to formatters in
MappedMatrixVis
can now be moved into thegetFormatter
utility function, now calledgetCellFormatter
.I add a type guard called
assertNdArrayValue
that allows narrowing down anNdArray
given an already narrowed-downDType
. After this type guard,dataArray.get(row, col)
is properly typed and we can pass the value to a strictly typed formatter without any casting.I'll do something similar in
ScalarVis
.The broader issue is that every time we narrow down a dataset object (e.g.
Dataset<ArrayShape, PrintableType>
=>Dataset<ArrayShape, EnumType>
), we have to narrow down the value right after withassertArrayValue
/assertNdArrayValue
/assertPrimitiveValue
(e.g.ArrayValue<PrintableType>
=>ArrayValue<EnumType>
). This is because we don't store dataset values within dataset objects. Maybe I'll try to tackle this one day.