Forget The Progress Loader In Your Angular Application
Do-and-forget general progress loader that will automatically and consistently show throughout your angular application
While the backend has a job of making sure the business logic is followed, the front end has a job of making sure the user can easily find what he’s looking for and finish their task. For that to work out, the user needs to look into consistent views and pages that look same or similar throughout your app. Call-to-action buttons need to look the same and be positioned in the same place, tables need to look and feel similar, details view as well. Your job as a front end developer is to make sure of this — and that’s not an easy job, considering you could be working on a larger team with developers with different ideas. That’s why it is of great importance that some of the repetitive things, such as progress loaders, are handled in a do-and-forget manner — you do them once and then they just work. That’s the easiest way of reaching consistency, albeit not possible in all scenarios.
Progress loaders are a pretty important UX component, as they give feedback to the user that something is happening. Most likely you are using one in your app. And most likely, the code looks something like this:
This will do the job, but I’ve come across a solution like this in a team of developers, and some views were missing the part where isLoading is not unset on error so the loader just went on showing, or views that had no loader at all. Some views, though, were done correctly, though by repeating this same code. So this solution proved unsustainable and produced inconsistent UX.
Even though there are some libraries for progress loaders, they still required you to manage them on a per component basis. We wanted to get away from that.
Solution
Our progress loader just shows whenever there is a network call, automatically, so you as a developer do not have to think about it. You don’t even know there is a progress loader actually, until you run your code to test.
What we did was, we put a progress bar on top of the application, so it was visible on all pages. You can do this in the app.component, or in another component in your app that makes sense. Maybe you have a toolbar that is shown above all pages, or you have some kind of home or layout component that is kind of a base for all other components — you can put the progress bar there as well.
Then, create a service with a single Boolean. The idea is to set this Boolean when there is a network call, and unset it when the network call is finished. However, the service will only declare the Boolean, but as it cannot know when there is a network call, it won’t do anything else.
Then, make sure that you show the progress bar when this service is true, and hide when it is false. A simple ngIf will do.
Finally, create an interceptor that will set and unset the Boolean in the loading service.
From this point on, you just don’t care about the progress loader. It will automatically and consistently show on every page whenever there is a network call, letting the user know something is happening in the background.
Conclusion
This will reduce boilerplate code in the components, letting the developers care about other stuff rather than consistency, as it will already be achieved.
If you repeat code in all components in hope to achieve consistency, you will fail. Sometimes developers will forget to repeat the code or will come up with a solution different than the previous one (I won’t blame them), or if you decide to change part of the design, it will become a tedious process to go over all of the components in the app and update it. This way, you have only one place to change it.
