Re: [fetch] XHR option to trigger busy indicators (#19)

>Also, note that webapps already implement their own progress indicators, and if XHR isn't handled properly, those can spin indefinitely too. 

This is why custom progress indicator is hard to get right. This proposal is supposed to address this issue, right? If you give developer a tool looks very simple, but actually difficult to use correctly, the result is not ideal.

Managing the state of busy indicator explicitly is actually very hard.

* Overlapping XHRs are hard to handle. You can't simply turn the indicator on when starting a XHR, and turn it off when the XHR finished or failed; instead, you need a global counter of pending XHRs. This can be impractical if a app contains many modules maintained by individual parties.

* You have to manage the indicator(or the counter) at every places you call XHR, this is a big burden. If you are on a large code base, and someone makes a mistake when handling the indicator, it becomes a nightmare of debugging. Maybe you can write a nice wrapper for XHR/fetch that automatically manages the indicator, you still have to enforce the whole team to use it everywhere -- but how about third party modules?

So, I don't believe average developers can get explicit busy indicator management right easily, not to mention those who copy-paste code snippets from arbitrary sites.


---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/19#issuecomment-102422234