Thanks for review.

Not sure how the performance was measured, but I tested on very low-end devices and the performance seemed pretty decent, comparing to other works on the same devices. (Samsung Grand Duos GT-I9080 2013, Huawei TA-1021 2017). I measured fps, memory usage and CPU, but maybe it was necessary to measure something else. I even didn't switch to using canvas and kept using svg only because the performance measurements seemed very competitive. 

Would be nice to know the performance testing criteria for the future. 

Thanks for the contest. Good experience.

But somewhat unfair results. Some poor performance works and works with no bonus tasks got rewarded leaving out couple better works including this one. It is a bit subjective, I know, but I think there are some grounds for my disagreement.

Yes, I agree with the video.

But this is not an error in the code or implementation. This issue has already been reported before and I replied.
The problem here is that the zoomed mode has all elements switched on by default even if you have deselected some in standard mode. I agree that this is not ideal UX, but I thought about it too late to implement.
The functionality itself works correctly and there are no breaks or errors though.

Yes, I agree. Unfortunately I forgot to sort it out and focused on other things. It's especially disappointing, because sorting it is a matter of 10-15 minutes.

Yes, agree. But there is no animation for that actually. I used to have the same animation that you can see when selecting/deselecting lines for example, but it seemed very annoying to me and I decided that this part of the app works better without any animation. I might be wrong, of course.

Yes, I agree with the screenshot. But the problem here is not in wrong values of the lines, but rather in not ideal rounding of the y-axis legend values.

I agree with the issue with buttons (this one has already been reported before and I answered to it),
 
But I can not reproduce the issue with pie chart. I don't want to think that this is another fake, but let me attach some screenshots for pie chart for the same date and the same sectors selection.

Yes, I agree. I decided to leave ES6 code as is for the contest purposes. Putting it through babel ( e.g. with webpack) makes it compatible with browsers that don't support ES6.

Thanks for the vote.

Yes, agree. I decided to concentrate on the main functionality and nice look. The date labels are positioned nicely and correctly anyways. There is a commented out piece of code in my .js file with the animation of the date labels, but I didn't like the result and decided to switch it off.

Disagree. The proportions (i.e. relative dimensions of the elements) are correct. This is not a bug. The functionality or layout is not broken. The tester just demonstrates more than 100% browser scale.

The y-axis colors are exactly as per the design specs at https://telegra.ph/JS-Design-Specification-04-07, but I agree that on some bright colors the labels would rather have more contrasted color.

Overruled as personal opinion :) The code btw is functional and pretty light-weight. No 3d party libs are used.

It is the intended functionality. The tooltip should not be hidden on mouse leave in my opinion. I think that is more correct from the UX point of view.

Disagree. The attached video demonstrates the long touch click for both mouse click and touch events.

Yes, that opens developer tools in Chrome. And by the way, my app is responsive and opening the tools doesn't effect the functionality and usability of it.

The attached video demonstrates the 6x CPU slowdown. You can see that the animations are working, the resize/search and zoom in or any other functionality is not stopped, frozen or broken. Though I'm not sure that having 6x CPU slowdown in dev tools is a legit way of qualifying apps for performance, to be honest.

I've also tested on low-end device (Samsung Galaxy grand duos gt-i9082 of 2013) and it works absolutely flawless there.

I don't see any issue in this report, to be honest.

If you are trying to make a code review, I would agree that my code has lots of things that could be improved, and I know that. But in limited time for development I had to concentrate on priorities first.

Thanks for saying that my work is excellent and for liking the animations.

As for the getJSON function in my code - it is actually used for both initial data fetch and for the zoom in functionality. In real-world scenario I would assume that the charts were implemented into some sort of ecosystem that already has its own function(s) for dealing with ajax. I would use such functions. Or write a wrapper function around my getJSON.

No need to be so radical saying that my code is impossible to be reused - that is far from the truth.

Can't reproduce.
The attached video demonstrates the correct work of 'dots' (a.k.a. circles) for line charts after navigating trough browser tabs.

Not sure what you mean by 'exact edges', but I don't see any problem with it in my work. The attached screenshot demonstrates how the pie chart looks.

Not sure what you mean by event loop. The sectors of the pie chart get separated and show tooltip on hover. If you hover over a sector - it works. Hover over another - it works too. The functionality is not broken in any way.

Might be that you are trying to pick on me and find some position of mouse cursor which would be exactly between two sectors to make jumpy hovering, but that is a bit irrelevant and even if considered an issue, then a very small one.

1. In the first video you clearly demonstrate that you try to pick on. I can see that the size of cursor compared to the size of the pie chart indicates some huge browser zoom. And in that zoom you are trying pretty hard to find that position between the sectors to make jumpy hover effect.
I would overrule such a report.

2. I attached a video, where you can see the correct url and the first thing is page refresh. In your video I'm not sure what has been done before - I can even assume you played with console or css a bit, taking into account previous picks. (Btw note the fonts and font weight of the texts in your video and in mine, and compare to the real work)

Really sorry that such things take place in coding contest. It's really demotivating. But I'm sure the telegram admins will understand that your comments here are just a kind of bulling.

I assume that a bunch of down-votes my work has received were by you and your friends out of hate and anger.

I disagree with this report.

Looks like this tester tries to pick on me.

The reports by Little Swan seem very biased and far from the truth.

I disagree with this report.

Looks like this tester tries to pick on me.

The reports by Little Swan seem very biased and far from the truth.

I disagree with this report.

Looks like this tester tries to pick on me.

The reports by Little Swan seem very biased and far from the truth.

Probably the screenshot was faked. Please see the video attached.

Probably a fake video report.
Please see attached a video with real work.

I 'played' and can not reproduce. Please see a video attached to the previous report

Disagree. 

I don't know how you do such screenshots. Taking into account your previous comments I would assume you just fake it. 

I can not reproduce the same issue.
Please see the _real_ video attached.

Agree. Small css issue.

I disagree with this report.

Looks like this tester tries to pick on me.

The reports by Little Swan seem very biased and far from the truth.

Code checked. The points sync fine.

I tested myself just now with 500% zoom - everything works as it should.

Anyways, I think you testing my work on 500% zoom demonstrates your intentions to pick on me. That's why your reports should be considered as biased and not valid.

- don't think there was a requirement to change button colors at night mode. The colors are coming from the data.

- best practices suggest to not disable standard browser features

- agree - non-critical small css issue

- the hitboxex have pseudo elements near them for better touch point, but I agree that subjectively it might be small for some fingers

- agree - percentage chart select/deselect doesn't have animations, the bar stacked chart has animations which are not very visible on small top Y value change.

- agree, I could reproduce this problem for situations when you go into zoom in state from 100% date range selection and then back.

Yes, I agree with this. But the problem is not that code doesn't work, I just initially thought that I need to keep separate states of selected elements for standard and zoommed modes. After deadline I realized that having the same state of selected elements between modes is much better UX, but was too late :(

Yes, absolutely agree. Thought about it, but was too late to implement.

Even in this video sample you can see that animation is happening. The other thing is that the animation is not very obvious for bar charts on small value change and I agree that this could be improved.

Yes, agree. A very small and non-critical issue.

Can not reproduce and not sure I understand what you mean.
The time range is selected by means of dragging/resizing the magnifier (search block) in the timeline (navigator)

Yes, I agree. It should display the from - to dates on hourly graphs if multiple days selected, but I thought about it too late to implement.
I have it working well for pie chart, should have implement the same for other hourly graphs as well.

Yes, I agree. Small issue - the tooltip receives the click event even before it appears. Could be improved. Though I would point out that the zooming happens for the correct date anyways.

Well, there are animations. I've made them a bit faster, because slow animations feel weird to me.
To see the animations you can select/deselect buttons on line charts or bars charts (though the animation is not very obvious on stacked bar chart - should have done it better). Also there are animations for zoom in/out and for horizontal lines and y-axis labels. The only missing animation is the stacked percentage chart select/deselect - simply didn't have time for it and it was low on my priorities list.

Yes, I agree. Thank you for this report - I haven't noticed it before.
I can confirm that it happens, though I could reproduce it on iPhoneX in Safari, but nowhere else :)
I guess it is due to bad handling of style.transform = "" by safari. Should have used a more reliable way to remove pie chart sectors separation.

Yes, I agree.
This has already been reported before by Funny Giraffe. This is a safari only issue. Should have used style.transform = "translate (0,0) " instead of emptying this property.

Yes, thanks for this report, I could just reproduce it myself and can confirm that there is such a bug.

It's something wrong with couple of dates - especially when there is big difference between the max and min values in some of the lines.

It's strange that if you view the 4th of June when entering the zoomed mode on the 1st of June - everything is correct.

Yes, I agree

A small styling issue for small screens that happens only at the middle of the chart.

The same issue has already bren reported earlier.