Closed pjanik closed 1 month ago
![]() |
![]() |
![]() |
![]() |
![]() |
Details:
Merge pull request #1370 from concord-consortium/187799270-IValueType-Date | |||
Project: codap-v3 | Commit: 86868a3a53 |
||
Status: Failed | Duration: 10:37 💡 | ||
Started: Jul 24, 2024 10:45 AM | Ended: Jul 24, 2024 10:55 AM |
View
Output
Test | Artifacts | |
---|---|---|
Graph UI > graph inspector panel > change points in table and check for autoscale |
Test Replay
Screenshots
|
View
Output
View
Output
Test | Artifacts | |
---|---|---|
Slider UI > updates variable name |
Test Replay
Screenshots
|
|
Slider UI > adds new variable value |
Test Replay
Screenshots
|
View
Output
Test | Artifacts | |
---|---|---|
codap toolbar > will open a slider |
Test Replay
Screenshots
|
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 85.52%. Comparing base (
e2edec3
) to head (7cdb8d9
). Report is 11 commits behind head on main.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
This PR aims to fix some design issues that were causing the following problem:
seconds(date(2020, 5, 14, 5, 4, 3))
orseconds(AnotherAttrWithFormattedDate)
was returning 0 because I used theformatDate
utility function, which formats the date to a locale string often without seconds, too early in the whole processing chain. The problem was that Date was not a first-class citizen type and was always stringified, and some data was lost.Here’s what I did to fix it:
seconds(date(2020, 5, 14, 5, 4, 3))
because nowseconds
receives a Date instance.importValueToString
to serialize Date to an explicit string format (I chose ISO string, as it's complete, can be easily parsed, and is relatively compact) because Date cannot be stored in any attribute storage (string values or numeric values). This also fixesseconds(AnotherAttrWithFormattedDate)
because each attribute now stores complete date information (ISO strings are a complete representation of a date). This is better than a number representing epoch milliseconds, as ISO strings can be easily interpreted as dates, unlike milliseconds which can be mistaken for regular numbers.use-columns
to recognize this ISO string and treat it as if it were an instance of Date. I believe the comments in this file explain that clearly.@kswenson, does this make sense to you? Another approach might be to have a "real" Date storage in the attribute, similar to strings and numbers. However, I'm not sure where and when even these numeric values are used, as often various helpers work with string values only (e.g. useColumns). And I'm concerned this would be quite a significant change. Also, you might have a better sense of how to implement this approach than I do. This is always an option for the future, as the current implementation does not lock us into it in any way.
Also, I did not update
attribute.toNumeric
to convert date strings to epoch seconds/milliseconds because I don't see a use case for it yet, and it would cause some performance overhead if we had to parse each string passed there, hoping it's a date.