-
Type: Task
-
Resolution: Gone away
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: CRUD, Performance
-
None
Add loading spinners in places known to be slow.
Scenario
1. Visit data.mongodb.parts
2. Open mercedes.laps_31k_x_4k5 dataset, documents tab (Issue 1, Issue 2)
3. Click "Show 1000 more fields"
4. Double click on a field (after the first 25) to edit it, rendering the 1025 fields (or 2025 or more if the user went further) can take a long time (Issue 3)
Issue 1
Fetching data from the server can take an unbounded amount of time (e.g. server never responds, server under a DDoS attack, rogue queries, etc).
Solution: Reuse the existing loading spinner for loading more documents:
Issue 2
See COMPASS-1764
Example with 110,592 fields (48^3):
Issue 3
As rendering can take a long time, the naive fix here is to let the user know it can take a long time with a rendering/loading text or spinner, depending on whether the UI is locked.
Aside: Longer term, getting field-based updates to work would allow the user to project only the fields they care about and then update just those fields, but there are no current plans to implement this.
Aside 2: This issue only affects edit mode, where the user has double-clicked on the specific field they wish to edit. Specifically clone, loading, cancel, update success and delete can all drop back to rendering just 25 fields, as they have no specific requirement to maintain the user's current context, and so are not affected.
Aside 3: Table view (COMPASS-652) if it got filtering of fields may also resolve this, as might adding a filter fields box into CRUD itself.