cypress[bot]
commented
1 month ago 1 failed and 5 flaky tests on run #3816 ↗︎
 1 |
 197 |
 28 |
 0 |
 5 |
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 | ||
cypress/e2e/graph.spec.ts • 1 failed test
View Output
| Test | Artifacts | |
|---|---|---|
| Graph UI > graph inspector panel > change points in table and check for autoscale |
Test Replay
Screenshots
|
|
table.spec.ts • 2 flaky tests
View Output
slider.spec.ts • 2 flaky tests
View Output
| Test | Artifacts | |
|---|---|---|
| Slider UI > updates variable name |
Test Replay
Screenshots
|
|
| Slider UI > adds new variable value |
Test Replay
Screenshots
|
|
toolbar.spec.ts • 1 flaky test
View Output
| Test | Artifacts | |
|---|---|---|
| codap toolbar > will open a slider |
Test Replay
Screenshots
|
|
codecov[bot]
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 theformatDateutility 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 nowsecondsreceives a Date instance.importValueToStringto 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-columnsto 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.toNumericto 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.