Do we (and to what extent) support dynamic content generated by e.g. views

[webchick]

If we're planning to handle the admin experience of Drupal, one of the big parts of the admin experience is content listings. For example, admin/people, admin/content, etc.

We did a lot of work in Drupal 8 to ensure all of these things are Views, and can be customized by the site builder without any development.

I don't think we want to lose one of the hugest benefits of Drupal (Views) during the React-ification. How do we balance this?

[tedbow]

We have REST views exports but right now it does offer the kind of functionality one might expect from a site building experience. For instance it will the REST view will not export the labels that set in the Views UI.

We could include all those types of settings in the Views REST export but also you could a JSON API request on the Views config entity to get all this information. You won't have to request the Views config entity everytime you used the page on the client side if there was a way to detect when the View was updated.

[dawehner]

For me Views consists of two major usecases

• Someone wants to be able to filter data and then theme it as wished. This usecase can be mostly supported by JSONAPI. If you need the more advanced features of views filtering etc. REST export, just as described by @tedbow, gives you the power needed. ✔️
• Someone wants to control the output of these listings. They want to provide some tables for admin listings, or some some list for maybe a custom admin dashboard. I think in order for Drupal to be a good content modelling and edit tool, some level of customized admin listings are needed. I also think this should not requiring you to code something, which is what point 1 is all about. ❓

[gabesullice]

If we're planning to handle the admin experience of Drupal, one of the big parts of the admin experience is content listings. I don't think we want to lose one of the hugest benefits of Drupal (Views) during the React-ification.

I think that this maybe too tightly couples "the admin experience of Drupal" and "the hugest benefits of Drupal (Views)"

Yes, using Views to create customized content listings is one of the hugest benefits of Drupal. I don't doubt that at all. But it's kind of a logical leap to say, "the ability customize the People page (with Views) is one of the hugest benefits of Drupal" (which is perhaps not what you were saying at all, maybe I misinterpreted)

To that I'd say that I actually think it's okay to lose some functionality in service of the "greater good."

E.g. if by decoupling the admin interface we can simplify it, modernize it, and make it a pleasure to work with then perhaps it would be okay to sacrifice configurability of some administrative content listings.

That would be a bummer because, as you said: "We did a lot of work in Drupal 8 to ensure all of these things are Views, and can be customized by the site builder without any development."

But to not consider this alternative because of that would fall into the fallacy of sunk costs.

---

We could include all those types of settings in the Views REST export but also you could a JSON API request on the Views config entity to get all this information.

I would really discourage going down that road. Views is built for the language of SQL, while JSON API is built in the language of HTTP. Trying to map those is going to be impossible without losing information and introducing bugs.

You could do something to "export" Views via JSON API (e.g. I can think of ways to make this work: /jsonapi/node/article?filter[view]=view_id), but you can't translate a Views query to a JSON API query.

[gabesullice]

It's also worth pointing out that the benefit of a decoupled UI is "decoupling data from presentation" which is, unfortunately, exactly what Views ties together.

To try to replicate Views verbatim in the great React-ification of 2018 is simply "recoupling" the frontend right back to the backend. It's just moving the rendering layer to JavaScript, which misses out on many of the benefits of decoupled and would be a really disappointing outcome of all this effort.

To do decoupling "right," we need to untangle the presentation and data primitive (read Views) so that one creates data exports entirely separately from how they're presented. I.e. you might use Views to "feed" a component on the frontend, but the presentation of those entities would be configured differently (a la Layout Builder or "manage display").

IOW, views would only be able to send the "rendered entity" display, but not the "fields" display. That would need to be handled differently.

[dawehner]

E.g. if by decoupling the admin interface we can simplify it, modernize it, and make it a pleasure to work with then perhaps it would be okay to sacrifice configurability of some administrative content listings.

For me it comes down to two points:

• Historically things weren't good and using views improved the situation, for example by having proper support for multilingual. We'd need to think of the full end product, when we want to rebuild the content listing for example, which means: how do you handle moderation, translation etc. I'd argue that is actually a good thing, unless what we kinda say right now: Oh yeah views, it'll be able to solve, somehow
• For customizations, we should still allow to replace a full "page" so that distributions / custom sites can improve things, if needed.

[tedbow]

I agree there are good reasons not try to provide Views integration for admin listing pages as an MVP.

I was wondering about a couple of things that might put off the need for this type of integration.

1. React APP won't take over all admin pages which seems like it will be the case until at least Drupal 9 because of contrib admin pages, could we set up a way for individual developers or sitebuilder to set that certain page the React app is built to take over should actually be controlled by Drupal

This would allow a site that has already customized the View that controls an admin listing page to keep their customization by continuing have Drupal serve the page with the View.

It would also allow someone to choose to serve a page the old fashion way with Views if they want to do something the React app currently can't

2. How could someone override a page on the React page? Will the current setup allow a React deve/loper on a site to replace the core React component with their own without "hacking" core's React code

[wimleers]

We did a lot of work in Drupal 8 to ensure all of these things are Views

Part of the motivation was "allow users to customize their listings". But also part of the customization was "less code to maintain, specifically wrt querying".

The customizability would initially be lost, yes, but the "less code/querying to maintain" bit would still be true when you decouple f.e. the content listing. The customizability could return at a later time. Also … isn't the complexity of the Views UI part of what we want to simplify? The only way people can customize their listings is by understanding Views' principles and learning their way around the Views UI.

fallacy of sunk costs.

Exactly. If we can only ever deliver a superset of what Drupal does today, we can never simplify/rethink.

simply "recoupling" … just moving the rendering layer to JavaScript

Exactly.

[dawehner]

React APP won't take over all admin pages which seems like it will be the case until at least Drupal 9 because of contrib admin pages, could we set up a way for individual developers or sitebuilder to set that certain page the React app is built to take over should actually be controlled by Drupal

The way how the current architecture works enables you to still fallback to routes provided by Drupal. I think we should totally keep this usecase around, given what Drupal already provides.

It would also allow someone to choose to serve a page the old fashion way with Views if they want to do something the React app currently can't

And I guess it is fine, as long we ensure that the JS listing is providing the much better user experience

[justafish]

To that I'd say that I actually think it's okay to lose some functionality in service of the "greater good."

and

The customizability would initially be lost, yes, but the "less code/querying to maintain" bit would still be true when you decouple f.e. the content listing. The customizability could return at a later time.

I very much agree with these statements 👏

I'm wondering whether teaching someone how to edit a React file might end up being easier (and a more transferable skill) than teaching them the Views UI. I think it'd be good to implement a non-to-very-simple configurable content listing in React, allow it to be overridden by a custom React component, and then do some user testing/surveys to see how people feel about it vs Views

[wimleers]

I'm wondering whether teaching someone how to edit a React file might end up being easier (and a more transferable skill) than teaching them the Views UI.

❤️ this! (But then again, I'm a developer, so I'm the worst person to ask.) At minimum, a very interesting thesis :)

[geek-merlin]

Since we have edit.module, views can render data binding metadata. We should be able to leverage that same metadata here. (display plugin for jsonapi / graphql?)