Add Custom Date Range to Gantt Charts Part 2 #5220
Conversation
✅ Deploy Preview for mermaid-js ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #5220 +/- ##
==========================================
+ Coverage 5.85% 5.99% +0.14%
==========================================
Files 274 274
Lines 41112 41167 +55
Branches 488 517 +29
==========================================
+ Hits 2408 2470 +62
+ Misses 38704 38697 -7
Flags with carried forward coverage won't be shown. Click here to find out more.
|
paldeep-singh
changed the title
paldeep-singh
changed the title
paldeep-singh
changed the title
|
For the changes to the GanttDb.js and GattDb.spec.js files, I had to commit without running the pre-commit hooks as ESLint kept crashing due to Node running out of heap memory, is that a major problem? |
|
I will review the PR soon, but mentioning some ways to share credit to original authors when forking.
|
Thanks, I did try #1, but could not pull the branch, will make sure to add a co-author to commits in the future! |
There was a problem hiding this comment.
Nice work @AlexMooney and @paldeep-singh. We need some more test cases and tighten up the syntax.
| it('should handle a dateRange definition', function () { | ||
| const str = 'gantt\ndateRange : 2023-06-01, 2023-07-01'; | ||
|
|
||
| expect(parserFnConstructor(str)).not.toThrow(); | ||
| }); |
There was a problem hiding this comment.
We need more test cases here.
And the behavior below is flaky. The format mentioned in the docs is not tested here.
So we should make it strict, then test and document it well.
dateRange 13:00, 14:00 fails
dateRange 13:00, 14:00 passes (two spaces)
dateRange: 13:00, 14:00 fails
dateRange : 13:00, 14:00 passes
There was a problem hiding this comment.
I've made it more strict by removing the logic that would attempt to parse the date using new Date after dayjs.isValid() returns false (see this commit). This change has not broken any tests, but I suspect it might break existing charts that are passing an invalid dateFormat while still successfully rendering due to that "backup" logic.
For valid date ranges, I've now included a test with a date-only range, a time only range, and a date+time range. Are there any other test cases I should add?
For the tests for invalid date ranges, I realised that depending on the specific error in syntax, the dateRange declaration could either be ignored or throw an error.
From your examples above, dateRange: 13:00, 14:00 would be ignored since the dateRange: (without a space before the colon) would not be considered a match by the jison parser looking for "dateRange"\s[^#\n;], and the dateRange would remain as the default of ''. For dateRange : 13:00, 14:00 (space before colon), the declaration would be picked up, but an error will be thrown as : 13:00 would be considered an invalid date. I've added tests for both these scenarios (see this commit), and would appreciate any feedback!
|
@sidharthv96 Thanks for the review! I'll address the comments over the weekend |
|
Sorry, just been a bit busy recently, should have time in the next couple of weeks |
Co-authored-by: Sidharth Vinod <sidharthv96@gmail.com>
paldeep-singh
force-pushed
the
feature/1530_gantt_chart_custom_range_2
branch
from
6980209 to
ec5b9b2
Compare
|
@sidharthv96 I have addressed your comments. There are 5 failing e2e tests, 1 is meant to fail and the other 4 are failures in the theme tests. I had to fix the syntax for |
|
@paldeep-singh can you fix the merge conflict please? |
Sorry, missed that one, done now! |
|
@sidharthv96 Is there anything else in this PR you'd like addressed? |
|
The latest updates on your projects. Learn more about Argos notifications ↗︎
|
📑 Summary
This PR is a duplicate of #4563, to resolve #1530. I am slightly desperate for this feature and did not want to trouble @AlexMooney for permission to fork his repo so I have simply copied his changes over into a new branch. Big thanks to him for letting me take over and for doing most of the work!
Most of the changes included in this PR are Alex's work, I have only done the following:
Actual date,Only startandOnly endthat Alex wrote in response to the one outstanding comment on his PR.Resolves #1530
📏 Design Decisions
[x] Remove all tasks which are completely outside of the custom range
[x] Force the x-range on the plot to match the custom range (though there might be some rounding)
[x] Allow setting an absolute range dateRange :2023-06-01, 2023-07-01
[ ] Allow setting a relative range dateRange :today - 7d, today + 30d (Alex suggested leaving this for future PRs and I tend to agree)
[x] Allow setting only lower bound dateRange :2023-06-01
[x] Allow setting only upper bound dateRange :,2023-07-01 👈 kind of strange; proposals welcomed
[x] Tests for the range values
[x] Manual testing with some screen shots (As mentioned above, would appreciate a second set of eyes since I this is my first contribution)
[x] Remove backup logic for parsing date with
new Date()if dayjs determines date provided is invalid.[x] Set default for
dateFormattoYYYY-MM-DDto prevent breaking charts due to above change if nodateFormatis provided. This change brings the code in line with the documentation[x] Fixed syntax for
titleanddateFormatin theme cypress tests. This has caused the snapshots test to fail. I have manually checked the new screenshots and the rendered chart is accurate to the diagram specified in the tests.Possible problems
dateFormattoYYYY-MM-DDmay break charts that are using the ISO 8601 extended date formatYYYY-MM-DDTHH:mm:ss.ssswithout specifying adateFormat. This would previously have been parsed by the (now removed) backup logic usingnew Date()which would run ifdayjsdeemed the provided date to be invalid. See comment.📋 Tasks
Make sure you
MERMAID_RELEASE_VERSIONis used for all new features.developbranch