Sometimes it is easy to forget that the end user might not have the amazing internet you have, I work from home on a 350mb fibre connection, so everything seems very fast. We should try to consider the end user who might not be on a good connection, or maybe they have one at home, but they are out and about on their mobile, things might not be so fast.
Consider this scenario, a react component with a form has button with an onClick callback that is in the form of an async function with a network request. When the network request completes invoke a callback passed from the parent that sets some state in the parent which results in the form closing. On my internet this all happens so fast that everything looks PERFECT.
Let’s consider it on a slower connection, the user has clicked the button and while that network request is in flight the form is still open, because the callback that sets the state in the parent component has not yet been invoked, the form remains open in limbo. What can then happen is, the user will think nothing has happened and start clicking the button again, this results in not only a poor UX, but also potential bugs with duplicate requests, state sets etc.
We can of course tighten this up with some disabled state/ spinner on the button, but the point was that we might not have even known we had to do this without the help of the network throttle, this great tool allows us to emulate a slower connection and see how our application might fair in the real world.
