Skip to content
This repository has been archived by the owner on Jul 29, 2019. It is now read-only.

Week scale - enhance and add to auto-scaling #3549

Merged
merged 5 commits into from
Oct 20, 2017

Conversation

knokit
Copy link
Contributor

@knokit knokit commented Oct 11, 2017

Changes:

  • Makes the week scale more consistent and removes clutter:
    • next() always adds 1 week to current date
    • move majorLabels to the 1st week in the month
  • Add week to auto-scaling (zooming)
    • replaces 5 days scale

Screenshots:
Before this PR: (keep this behavior)
week_scale_orig

After this PR: (reverted)
week_scale_new

Live examples:

@knokit knokit changed the title Move majorLables to 1st week in the month, for 'week' scale Week scale - enhance and add to auto-scaling Oct 11, 2017
@@ -73,7 +73,7 @@ TimeStep.FORMAT = {
hour: 'HH:mm',
weekday: 'ddd D',
day: 'D',
week: 'w',
week: 'D',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't quite understand why to choose the "Day of Month" as default instead of "Locale week of year" when local-aware moment.js is defined as a requirement. Besides, it seems to be more safe to choose the local-aware moment.js week, you never know what happens within these locales.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason for that is to be consistent with the other formats, so when your zooming it doesn't jump from number of the week in the year to day of the month.
This can then be overridden to fit specific cases using format: { minorLabels: {week: 'w'} } as shown in this example: weekStyling

}
}
break;
case 'week': this.current.add(this.step, 'week'); break;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I absolutely disagree with this change, which causes the first day of the month to completely disappear. In fact, I believe that showing the start of the month is mandatory, it is at least for me and so far I haven't seen anybody complaining. Week starts do not necessarily align with the start of the month. With this change, there is wrong information displayed, e.g. giving the user the impression that the month starts right with the start of the week, as is visible in your initial comment for this PR #3549, e.g. in September 2016, (ISO) week 37 started on the 12th of September. Also it is not consistent, because July looks like it was 5 weeks long. That's why I went through all the hassle with this admittedly ugly piece of code. But please leave it as it is, and maybe apply your own patch or make it configurable if you don't like it.

Copy link
Contributor Author

@knokit knokit Oct 11, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know that this changes a bit your initial implementation, but it's more generic and consistent with the rest of the code, i.e. creates a regular scale that iterates only weeks (as we are creating a week scale), without exceptions.

The rest is just a matter of label formatting, if the majorLabel seems a bit misleading it can be changed for D MMM YYYY instead. But again, this can be modified using format: { majorLabels: {week: 'D MMM YYYY'} }

It's not a matter of disliking the current solution, it's instead an attempt to make it more consistent with the rest of the code, usable for other cases and customizable.

You're right about those issues. Months as majorLabels and week numbers as minorLabels don't work really well together, perhaps because 'week numbers' are relative to the year...

Thanks for reviewing the code. :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see your point and agree that this approach is more consistent. But I'd like to suggest to at least change the major label default to D MMM YYYY if you think this change is absolutely necessary. Otherwise you get the impression of a wrong start of the month. For me, this change makes the week scale more or less useless because I really need and want to see the beginning of the month. What imho is really needed is a more flexible/independent approach to draw the major and minor labels and lines as requested in #3323. Please reconsider.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tend to agree with @marcortw . The weeks don't always align with the month so the current behavior is much preferred to me.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I have to agreed with you guys. It's rather confusing. I'll revert this change and keep the current behavior. ;)

Can we still add the week scale to the auto-scale? It could replace the 5 days scale (or keep both?) and by default its minorLabels would display the "day of the month". What do you guys think?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with that, thanks! I initially had the weeks in the auto-scale but then left it out because I thought that people might be confused by the week number, it's probably a bit of information that is not used by many people.

@wimrijnders
Copy link
Contributor

@knokit Can you please fix the build? Travis reports the following:

/home/travis/build/almende/vis/test/PointItem.test.js:15
  var now = moment();
            ^

TypeError: moment is not a function
    at Suite.<anonymous> (/home/travis/build/almende/vis/test/PointItem.test.js:13:13)
    at Object.create (/home/travis/build/almende/vis/node_modules/mocha/lib/interfaces/common.js:114:19)
    at context.describe.context.context (/home/travis/build/almende/vis/node_modules/mocha/lib/interfaces/bdd.js:44:27)
    at Object.<anonymous> (/home/travis/build/almende/vis/test/PointItem.test.js:10:1)
    at Module._compile (module.js:570:32)
    at loader (/home/travis/build/almende/vis/node_modules/babel-register/lib/node.js:144:5)
    at Object.require.extensions.(anonymous function) [as .js] (/home/travis/build/almende/vis/node_modules/babel-register/lib/node.js:154:7)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)
    at Module.require (module.js:497:17)
    at require (internal/module.js:20:19)
    at /home/travis/build/almende/vis/node_modules/mocha/lib/mocha.js:231:27
    at Array.forEach (native)
    at Mocha.loadFiles (/home/travis/build/almende/vis/node_modules/mocha/lib/mocha.js:228:14)
    at Mocha.run (/home/travis/build/almende/vis/node_modules/mocha/lib/mocha.js:514:10)
    at Object.<anonymous> (/home/travis/build/almende/vis/node_modules/mocha/bin/_mocha:480:18)
    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)
    at Module.runMain (module.js:604:10)
    at run (bootstrap_node.js:383:7)
    at startup (bootstrap_node.js:149:9)
    at bootstrap_node.js:496:3

@knokit
Copy link
Contributor Author

knokit commented Oct 13, 2017

@wimrijnders, not sure how can I fix it. I haven't change anything connected with the tests and they all passed when I ran them locally. Any suggestions?

@wimrijnders
Copy link
Contributor

OK understood. This has happened before. The thing to do here is to retrigger the travis test by submitting a new commit.

I suggest you merge the PR with the latest develop branch and resubmitting. Someone has to do that anyway at some point. If that's not enough, make a tiny change somewhere and submit that.

@knokit knokit force-pushed the feature/week-scale branch from 6339364 to fb4965f Compare October 13, 2017 12:16
@wimrijnders
Copy link
Contributor

Yay! 👍

@knokit
Copy link
Contributor Author

knokit commented Oct 13, 2017

@wimrijnders, thanks! 👍

@wimrijnders
Copy link
Contributor

Thank you for getting this done!

@wimrijnders
Copy link
Contributor

wimrijnders commented Oct 15, 2017

Travis test failing not your fault. I had this zany idea to add a stress test to the unit tests, and sometimes it exceeds the time out. Remedy is same as before; otherwise I'll adjust the timeout in question.

Edit: You might try merging with develop at this point. #3518 should make the unit testing a lot faster.

@knokit knokit force-pushed the feature/week-scale branch from f23f636 to 35ab69a Compare October 15, 2017 09:39
Copy link
Contributor

@yotamberk yotamberk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome! Thanks for the PR!

@yotamberk yotamberk merged commit 0a6f257 into almende:develop Oct 20, 2017
mojoaxel pushed a commit to visjs/vis_original that referenced this pull request Jun 9, 2019
* Move majorLables to 1st week in the month, for 'week' scale

* next() always adds 1 week to current date
* show 1st week in the month as majorLabel

* Add 'week' to auto-scale

* Update week scale example

* Revert "Move majorLables to 1st week in the month, for 'week' scale"

This reverts commit 52df3c3.

* Correct value of week's minimumStep
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants