5 ms·
I like this approach, but one problem with plain javascript that I haven't heard many people address is testability. A module I am using with angular has lots
by tynpeddler 10y ago
I like this approach, but one problem with plain javascript that I haven't heard many people address is testability. A module I am using with angular has lots of calls to setTimeout, but these timed out functions are sometimes not invoked until after a test had cleaned up the DOM in preparation for the next test. The timeout function fires and then throws an error because none of the elements it expects are on the page.
Libraries that set a lot of native key handlers can also be problematic. Native browser key events are a pain to mock, and the same mocking techniques are not available in all browsers. If you want to unit test in all browsers, you have to write some truly hideous tests.
The fact is that a lot of browser API's are terrible, and tools like jquery can help smooth over browser differences and make it easier to test your code that relies on a library.
- spankalee 10y agoYou don't need a whole framework to intermediate events and timers. One approach is to have a library that you call instead of the native addEventListener, setTimeout, etc. method. Another is to use something like zones.js which does this for basically ever async API in the browser, and then use test utilities that let you play with time, like flushing all timers, or advancing time by specific amounts.
- tynpeddler 10y agoBut if you write your library to use those sorts of tools, then you now have a dependency, which the article is arguing against doing.
- spankalee 10y agoThe article is not arguing against dependencies. It's arguing against tying your library to a specific web framework.