Angular — Managing UI State with async data
A comprehensive guide for loaders, errors, and empty states
How do you handle user waitings? What happens when some page content fails loading?
We will review some basics from Material Design guidelines and expand the last article about Atomic Design. Take a coffee, and feel free to join! ☕
The principles
Great designs go beyond colors, shapes, and happy paths. They handle server errors, empty states, and asynchronous content with elegance.
Even the bad scenarios are integrated as part of the show to keep the user engaged.
Material Design offers a comprehensive guide to the underlying principles of a good UI. Beyond implementation details, we can simplify the theory in two core goals for enhancing the user experience:
- Reduce user uncertainty
- Provide visual feedback of progress.
The basic UI States of a component
- Empty state
According to Material Design, “Empty states occur when an item’s content can’t be shown.” I would complement this by saying ‘because it is yet to be created’. Think as an example: the recent messages in the user inbox when the server response is an empty array. - Error state
Servers may crash, the petition may timeout. Don´t let your user staring at a spinner forever. Design 404, app crash scenes.
A bit of a sense of humor can keep the user engaged. - Loading state
Spinners, loading bars & and placeholders are designed to provide visual feedback about the loading progress. Creating balanced animations is a must in high-quality designs. Transitions can be scary at first, but thanks to guides like Understanding Motion, a little patience, and a few sessions of put wax, remove wax you can achieve some impressive results. - Loaded state
When everything is ready, it´s time to render the component that displays the actual data.
The structure: A template component for every UI state
Remember the last article I wrote about Brad Frost Atomic Design? Let's go deeper into the template concept.
Loading & empty states are static content, plain HTML & CSS. They are perfect candidates for template components.
Page-level components are smart. They often control the flow and data of more than one widget. By having the templates split into smaller components, you play ‘divide and conquer’ and keep the page simple.
As good designs have some consistent theme, you will probably start to see patterns between your templates, and refactor some of them as shared components when the app starts to grow.
The process: Handling state transitions between Service & page component
- List the UI State values in an enum
By default, enums assign increasing values to every key starting at 0. (Not initialized is 0, loading is 1…).
This is important, as we will compare these numeric values to determine the next state.
- Create a UI State observable separated from the data observable
To store the UI State value and determine which template should we load next we will use an Rxjs Behavior Subject. A multicasting observable that always has an initial value, and emits its current value anytime a new subscription is made.
- Trigger loading state
Depending on the component, when the user interacts or the page loads, we set the UI State value to loading (1) right before making the HTTP request.
- Analyze server response to set the next UI state
When the HttpResponse arrives the state will emit new data values.
We can use a tap operator in the service to analyze the incoming data and trigger the next UI State.
When we got the the server response we analyze the incoming data. Is it empty? Is an error? Depending on the result, we set the next UI State.
If you are using state management with stores, avoid the common pitfall to add the UI State in the data layer. Use a facade service. By doing so you can create UI States for combined HTTP Requests and multiple selectors without altering the individual data models.
- Subscribe to observables in the page component
Notice that the search-data component only renders when the UIState is loaded. This allows us to differentiate between an empty state that may come after an HttpResponse (like empty arrays) and the initial state, which is normally a null value.
Voilá!
The final result is a page, smart component with an easy to read HTML.
Now that the setup is ready, it's time to play with CSS and Angular animations to give the transitions between template components the professional touch we want them to have.
Did you find the article interesting?
What is your opinion?
As always,
Thanks for reading! 🙂
