DataViews option persistence

[jameskoster]

In DataViews there are various configurable options that you'd expect to persist across sessions. For example changing the number of items per page, or the fields that are displayed. Currently this is not the case.

There is also a question to answer about whether view options should be tied to layout, or the overall view. For instance if I'm viewing All Pages and change the 'items per page' option in Table layout, should that also apply in Grid layout?

[bgardner]

Huge fan of this, particularly for Layouts (Pages and Templates) which seem to have inconsistent defaults anyway (Grid and List, respectively). Full disclosure: I prefer Table view on both, so having persistence once I set to these views would be amazing.

[bacoords]

+1 and this is making me wonder if we need a full "Visual State Persistence" tracking issue as this keeps coming up across the user interface (CC @annezazu)?

The site editor should consider including at least some ability to keep some of these visual views in some sort of state or local storage for each individual screen so that everything doesn't always get reset every time you click into a single post object to edit it.

[kubiqsk]

I believe that everyone will be happy with a table layout as a default option everywhere,
because this is crazy resources expensive to render all the block in all the templates once you click on Templates in sidepanel in Site Editor.
I'm trying to find any solution for this, because people are getting really angry about freezing browsers...

[oandregal]

Added three more features (user choices) that would benefit from being persisted:

• Data views: allow users/consumers to pin rows in table layout #64678
• Data views: allow users/consumers to pin columns in table layout  #64679
• DataViews: Allow users to configure which actions are primary #65600

[jameskoster]

I updated the OP slightly. I think there's a bigger question to answer about what the persistence is attached to; the different layouts within the view, or the view itself.

I lean slightly towards the layout, as they're optimised for different workflows. For example in Table layout it probably makes sense for many fields to be visible. But Grid layout is more visual; in most cases it's desirable to show only one or two fields. As a practical example in the shipping software, template descriptions are useful in Table layout, but in List layout they're kind of overwhelming:

@oandregal perhaps you could clarify how things work currently? @youknowriad I suppose this could be related to #67391.

[youknowriad]

@jameskoster If I'm understand properly, your question is about what happens when you switch layout, rather than persisting on page load right? I think both options are possible (keeping the fields or resetting the fields to a default defined per layout).

[jameskoster]

Yes. Something like this sounds about right to me: if you change a view option in Grid layout, it affects only Grid layout, and if you refresh the page the option persists.

I suppose we'll also need to think about adding a 'Reset' button to the view options dialog.

We may also need to explore the layout switching UI to see if we can better communicate the relationship between layout and view options.

[oandregal]

There is also a question to answer about whether view options should be tied to layout, or the overall view. For instance if I'm viewing All Pages and change the 'items per page' option in Table layout, should that also apply in Grid layout?

Running with James example and attaching the view config per-layout:

1. Page loads and items per page are 20 (the default).
2. User switches to 100 items per page.
3. User switches to grid layout. Because view config is attached to the layout, the items per view here will be 20 (the default).
4. User switches back to table layout. Items per view are 100.

Conceptually, it makes more sense for me to attach changes to the view. One reason is the "distance from when I made the decision": as an user, perhaps I did 3 today and I'll do 4 in four days. If I don't remember that I had switched the items per page for table I'd find surprising that it is now showing me 100. UI-wise, if we go with that model, I think we should expose all that info to the user (all view config per layout).

I find the per-view model easier to reason about. If you want to configure two different views, you can save two custom views.

[oandregal]

@oandregal perhaps you could clarify how things work currently?

The view config is as object that contains the layout type as well:

{
  type: 'table',
  perPage: 20,
  filters: [ /* ... */ ],
  /* ... */
}

A custom view saved by the user stores that object in a CPT. If we wanted to save different view configs per layout, we'd have to change this to something along these lines:

{
  'table': {
    perPage: 20
  },
  'grid': {
    perPage: 100
  }
}

[jameskoster]

@oandregal I don't know. You may have a view where you frequently switch between layouts, and expect each one to appear a certain way. I could see this being useful in the Media library for example; Grid shows no fields and is used to quickly identify/edit media items, Table shows a bunch of fields so you can quickly sort and perform (bulk) actions. If all options are tied to the view then you couldn't do this, you'd need to have two separate views "All media (Grid)", "All media (Table)"? It seems a bit less flexible, but maybe that's not a bad thing?

I don't have a strong feeling either way, so am very keen to hear more feedback. If we allowed each layout within a view to have it's own config then I think we'd need consider giving increased prominence to layout in the UI, to make that connection clearer. Rough mockup: