Which capabilities should modules have in a new JS based admin UI

I guess the capability to opt-out of react is of the table by now ;)

But in all seriously it would be very appreciated if every module that touches the frontend of a site in some way, like quickedit, contextual links, inside-out etc would be excluded from the new JS admin UI. So instead of discussing what modules should do, perhaps we also should discuss what modules should NOT do.

And yes I know this is going to make it harder for the whole transition process, but that's the only way we can allow frontenders / themers to choose the frontend framework they want or need to use for a front facing theme without being restricted to the choices of the admin system/ theme.

Most of the core libs like jQuery can be disabled with relative low impact on the rework needed in another framework as most of the logic is doing some form of direct DOM manipulation. However with the non existing in-operability of various VDOM solutions (React/Vue/Angular etc) it would imply that all logic needs to be rebuild per solution or implement a lot of extra code to send events from System X to System Z. Not taking in account the speed decrease that will bring to the table.

But in all seriously it would be very appreciated if every module that touches the frontend of a site in some way, like quickedit, contextual links, inside-out etc would be excluded from the new JS admin UI.

I think this is a pretty sane proposal. One additional thing to keep in mind is some things, like entity edit forms (maybe it's just the node ones) can be both front-end and back-end. This would exclude most of our Widgets.

Personally, I think the Manage Display and Manage Form Display forms are good (probably easier) candidates for experiment. Both already use AJAX, but can be quirky (like edit a field setting, but then you still have to save everything).

At the other end of the spectrum, I think the Views config would be the biggest winner. Lots of AJAX already, and a pseudo-reactive preview.

Views, Media, the content list, module overview, logs, are all very good candidates for moving the a reactive system.

Field UI would be awesome, but that is a rather tough nut to crack, because those fields can be used in front facing code to. Perhaps some progressive enhancement should be taken in consideration when it's time to move those system into a reactive UI.

I would hope that the ultimate goal and target of our JS enabled modules is to provide standard compliant ES6 modules. We've already announced (in this change record https://www.drupal.org/node/2815083) that Drupal is to use ES6 modules for including javascript functionality.

In doing so, it would technically be feasible to implement new js-enabled administrative capability in such a way that hides the implementation of of new administrative components. If we can do that then it would be technically feasible to replace the implementation with something else.

Going through that level of effort makes sense for Drupal. After all, didn't we just through a huge effort to add a ton of PHP Interfaces to Drupal? What was the goal of that effort? One goal was to make it easier for folks who wanted to provide additional or overriding implementations of an object.

Now, JavaScript doesn't have interfaces (duh, dynamically typed language). But Typescript does: https://www.typescriptlang.org/docs/handbook/interfaces.html

If we're already worried that adopting React might mean locking Drupal into a specific platform's implementation / requirements. Perhaps it would be worthwhile to study if abstracting the implementation details and using interfaces would make it easier to replace the implementation with something else.

A bit of digging into the React ecosystem revealed Flow to me. Looks like there is a preference to use Flow instead of Typescript and it supports interfaces too: https://flow.org/en/docs/types/interfaces/

Ah yes, seems that I went off track.

I concur that including a javascript framework adds quite a lot of capability. It seems like it would be more work to have an inclusion list of functionality that we permit than to attempt to restrain specific usages.

I think your focus on routing is important. When we have a system where we basically have 3 frameworks that care about routing (Drupal, Symfony and the JS Framework) we'll have to provide guidance for when the platforms conflict.

We done this kind of mediation a lot with Drupal + Symfony, as can be seen in all the work that went into the menu / routing system in the years leading up to the release of D8.

We could decide to avoid rehashing routing issues by having the JS framework reuse Drupal's routes rather than providing a new way of defining routes.

In short, I would prefer to continue our current ways of defining routes.

i was pondering a bit more over this last weekend and had some of Wim Leers his words in the back of my mind. At DrupalCamp BE he spoke about the API first initiative and perhaps dogfooding it in Drupal core.

Most of the core admin stuff could be partly or perhaps even fully done with using a JSON API as a base. Or at least I think that should be possible, not 100% up to speed with all of the code in core.

But going this route a module could or should declare various endpoints for admin functionality and any given frontend could implement those according to the spec.
Again, i'm not 100% sure if that's feasible within a bordered timeframe of this issue, but it would make it 'easier' to swap between various reactive frontends. The heavy weight of the admin system will be in the API endpoints and not in a framework coupled codebase.

So :

As a module I want to expose JSON API endpoints for my logic

Most of the core admin stuff could be partly or perhaps even fully done with using a JSON API as a base.... As a module I want to expose JSON API endpoints for my logic

Yes! That is also what Dries recommends in https://dri.es/drupal-looking-to-adopt-react:

We need to keep investing in Drupal's web service APIs. At a minimum, we should expand Drupal's web service APIs and standardize on JSON API. Separately, we need to examine how to give API consumers more access to and control over Drupal's capabilities.

#2842148: The path for JSON API to "super stability" is the issue for what still needs to happen in the JSON API contrib module before it's ready for inclusion in core. Meanwhile, #2905563: REST: top priorities for Drupal 8.5.x is the issue for top priority improvements to make in REST, many of which will also benefit JSON API endpoints as well, once core is ready to convert to JSON API.

The heavy weight of the admin system will be in the API endpoints and not in a framework coupled codebase.

Yes, but core will continue shipping with UIs in addition to APIs. And so, this issue still needs to decide on how contrib modules that want to extend or customize those UIs can do so. If a contrib module wants to completely replace a UI entirely, then yes, it can do so by connecting solely to the JSON API endpoints. But I think we also want to flesh out cases where a contrib module wants to make small customizations to core's UI rather than fully replacing an entire UI.

If and only IF core wants to replace the entire backend in a reactive JS, all the elements must be converted or adapted to this. So yeah forms and form elements should be included. One of the major challenges in going this route will be UI/UX consistency, aka one admin theme to rule them all. That goes directly into the current Drupal foundation, but looking at it from a editor/user point of view it is inevitable. We can't maintain several UI styles mixed into one like we have now (Panels, Views, FieldUI and Rules pop to mind while writing this)

Perhaps this goes beyond the scope of the 'let's prototype one admin screen in React', but in the long run consistency is and should be a key factor.

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!