In yolotower we use the Loading... spinner down in the bottom right corner to indicate that we're interacting with the api. We also slap a transparent div over the entire application to prevent the user from clicking on anything while we're making our requests.
We'll want to establish a ux flow around "loading" when:
a) Initially loading a list
b) Navigating from one page to another
c) Sorting the list
d) (In the future) performing a search
We have the current loading screen mockup:

My initial impression was that this would be shown _instead_ of the list during the aforementioned actions but as @marshmalien pointed out to me, this would cause a flash when going from page to page which we currently don't have.
I've opened up this issue to track discussion and eventually outline exactly what needs to be implemented.
After discussing this issue with @mabashian and @trahman73, we've proposed the following:
List is in a loading state (fetching data), resource count is unknown:

List is not in a loading state. There are no resources:

List is not in a loading state. There are resources:

List is in a loading state:
List is in not in a loading state. There are no resources:

The other thing we will want to make sure of in terms of this feature is that loading doesn't cause a lot of flashing (panes going away and coming back on the screen). The pane itself should probably have a min-width or something so that it looks smooth as it transitions between these states.
Relevant: React is expecting to add Suspense for data fetching to their API mid-2019: https://reactjs.org/blog/2018/11/27/react-16-roadmap.html#react-16x-mid-2019-the-one-with-suspense-for-data-fetching
I don't know if we can wait that long before implementing this, but it's worth keeping an eye on
Note that https://github.com/ansible/awx/blob/devel/awx/ui_next/src/components/ContentLoading/ContentLoading.jsx is in place until we come up with a solid plan.
http://patternfly-react.surge.sh/documentation/react/components/spinner is now a thing. We should probably be using that as the spinner.
Skeleton loader is coming in PF: https://github.com/patternfly/patternfly-react/pull/4755. When that lands we should look at making the switch. Going to mark this as blocked for now.
Note that this loading state should apply to more than just lists. It should apply to anywhere that we want to show a loading screen while data is being fetched.
When deleting/disassociating batch of resources as well it would be nice to display loading... or give the user a feedback of the action being executed.
@AlexSCorey @tiagodread let's perform a lighthouse performance test with and without this change
Relevant: React is expecting to add Suspense for data fetching to their API mid-2019: https://reactjs.org/blog/2018/11/27/react-16-roadmap.html#react-16x-mid-2019-the-one-with-suspense-for-data-fetching
I don't know if we can wait that long before implementing this, but it's worth keeping an eye on
Me in November 2020: 馃ぃ
PF says the Skeleton should be used in places where we know what we are waiting on and what form it will take...otherwise use the spinner. https://www.patternfly.org/v4/components/skeleton/design-guidelines#usage
@AlexSCorey @unlikelyzero @mabashian in terms of testing, it鈥檚 been a pain know when the page is fully loaded because sometimes we have nested requests, I wonder if is possible to throw up an event that could be easily listened by the test, to know when the page is safely fully loaded.
There's a Open UI Automation standard that helps make it easier: Page Safe
please update this ticket when the work is completed https://github.com/ansible/awx/issues/7004
Verified that the loading spinner is displayed across ui next while fetching data, also added a e2e test in https://github.com/ansible/tower-qa/pull/5861
Most helpful comment
Me in November 2020: 馃ぃ