When To Implement
In almost all instances where API activity occurs, we need to provide loading/activity feedback to the user. This includes initial page loads, page refreshes, data filtering, and form submissions.
Proximity/Locality
The loading indicator should occupy space in the most relevant container. Which container is most relevant depends on the context. In most cases, this depends on the action that began API activity.
Indirect Action (routing, initial view load, refresh)
For instance, if data retrieval occurs on initial page/view load, then the appropriate container would be the main content area. This indicates to the user that no interaction can or should be taken until data is retrieved. When a view consists of multiple, distinct content areas (e.g., dashboards), then each content area should have its own loading indicator. Please note that accomplishing decentralized statefulness such as this requires more local, granular component Redux state management.
Direct Action (form submit, pagination, filter)
If taking a specific action, the user should not be allowed to take the same action again until the first has completed. For instance, when performing create or update actions, the loading indicator should cover or encompass the submit button itself.
For direct actions like paginating a datatable, use the datatable container to hold the loading indicator.
Duration
The loading indicator should display until we have a response from the API and the response data has propagated through the Redux store. Typically, the end of loading/activity indication marks the beginning of a subsequent notification, such as a success or error toast.
Implementation
For available implementation components, see: