Tests and tweak for Interval component

[philip-peterson]

Hi! Thank you for making Dash, it is a very helpful platform for quickly creating visualizations. I was using the Interval component the other day and found out that there is some trouble with the disable prop (I made an example to show how). So I added some tests and made some tweaks to the Interval component, hopefully the fix is useful to you!

Cheers,

• p

[alexcjohnson]

Thanks @philip-peterson! The fix looks good, and quite a bit clearer code too 🎉

I linted and rebuilt (we're intending to change the process so built files are published only with releases, but for now we're building in every PR). That said, eslint is still complaining about the console.warn on a redundant startTimer call. I think we have that rule in place because console messages are not a level of debugging we want to persist in the final code - either a) this is a severe enough problem that it should throw an actual error, b) it's not an error at all and we should just return silently, or c) we should treat this as equivalent to resetTimer, and clear and restart the interval. I don't think (a) makes sense, probably I'd go for (b) but could be convinced for (c).

FYI I should just note that events are about to disappear (see plotly/dash#531) but I'll take care of reconciling that with the work and tests in this PR after merging.

[philip-peterson]

Hey Alex, thanks for taking a look at this so quickly! I thought about it a bit, and actually I think option (A) is what would make the most sense. Since we are talking about a situation that should never occur -- the code is written in a way that should not allow it to happen -- we would want to know if something has gone wrong, because it means something in the code isn't written the way it was intended. That eliminates option B. As for option C, if someone is managing to go down this path, it is by accident (either on their part or ours), and the last thing a developer wants alerting them of a mistake that they made is the presence of some subtle, slightly different behavior from what constitutes normal operation. So that would rule out option (C).

The argument against option (A) I can see as being that, well, if the component is broken then we should at least try to proceed with execution. But, I would counter that attempting to proceed with executing code known to be broken is doomed to fail.

Let me know what you think of all that. Pushed up a couple new commits to fix that lint issue mentioned and also ran prettier on all the tests. Thanks again!

[alexcjohnson]

OK, as long as we have sufficient test coverage to be comfortable that this error is never thrown, which it looks like we do, I can support throwing an error.

@Marc-Andre-Rivet this is a 💃 from my standpoint, any comments before I merge it? (I added a changelog entry just now FYI)

[Marc-Andre-Rivet]

💃. Thanks for reaching out to us with these fixes and improvements @philip-peterson!

[philip-peterson]

Thanks @Marc-Andre-Rivet and @alexcjohnson ! This ticket can be marked as solved btw: #325