Problem/Motivation

In the original issue #2645250: [META] Supersede Backbone in core admin UIs with a new client-side framework the investigation/feedback step is missing from the process. From the previous thread what needs to be addressed is enabling a standard way to do optimistic feedback (aka progressive decoupling).

This issue is about gathering this feedback properly so we can agree on the scope of what this thing should be. Starting with looking at where and how a frontend framework could be used for in Drupal admin UI.

Proposed resolution

As attiks said in the other thread:

Maybe a first step is to create separate issues and define a single use case in each so we have a list of pain points, this will make it easier to define what needs to be solved and how it might be solved.

Remaining tasks

  • Investigate potential frameworks and agree on the criteria to select such a framework.
  • Demonstrate that such a framework would work for our situation (Create proofs of concept).
  • Determine when the frameowkr should be implemented and implement it.

User interface changes

The child issue is ignoring all the UX work needed to achieve some of the goals. In any case the amount of JS work will be tiny (whatever solution we choose, including custom) compared to the amount of work needed to come up with a design and agree on it.

Application-like UIs in Drupal (e.g. Views UI and block placement) would benefit from a standard framework to enable a fluid experience.

API changes

None.

Data model changes

Likely none.

Comments

nod_ created an issue. See original summary.

nod_’s picture

Issue tags: +Usability

areke’s picture

Issue summary: View changes
andypost’s picture

Suppose listing of menu items and taxonomy terms are nice examples to try

attiks’s picture

nod_’s picture

Dries' reasons for pushing this: http://buytaert.net/turning-drupal-outside-in

From what he said in the post, what we need to take as an example is be the content modeling UI, implemented in different frameworks. Since trying to integrate that with Drupal in a progressive decoupled mode will be more painful than just throwing a UI together with one's framework of choice, core 'only' need to coordinate efforts for now.

droplet’s picture

the biggest problem now is "Missing a Model Data Layer in Drupal's JS". Therefore, we can't redirect the flow to other client-side system easily.

Some problems, For example:
#2662932: Drupal.file.progressBar doesn't replace APC_UPLOAD_PROGRESS|UPLOAD_IDENTIFIER in time
We can see that binded the events everywhere.

#2561619: Drupal Ajax objects and settings grows endlessly
We keep settings but missing sync. It pretty useless in most cases. also, there's no way to get the target instance from Drupal.ajax.instances.

#2542050: Toolbar implementation creates super annoying re-rendering.
It's using Backbone. However, I think it's misused this framework in many way (I called it Drupal-Backbone-Way). It didn't fully use Backend Model for data. It's almost unable to change pre-made features. Stuff also mixed in different controllers, also almost all events binded to .render()... (very hard to understand / test basic things)

#2293803: Replace confirm password field with show/hide functionality
Almost all Drupal's JS functions are not accessible in public scopes (also, not configurable, I also called it as Drupal-Style, always design for Core only).

Taking above issue as example, if we want to change a bit of code, it's not that easy:

+++ b/core/misc/revealpass.js
@@ -0,0 +1,59 @@
+  var showPass = Drupal.t('Show password');
+  var hidePass = Drupal.t('Hide password');

To me,
First: a new workflow for Core Issue (both JS and HTML/CSS), deploy it to development branch as quick as it can. To commit 99% good patch in ultra fast mode for 99% users and don't let the 1% blocking other patches bug fixing. If we checking other GITHUB projects / WP, that's working in this way. Most of developers are not fully funded by Drupal Firms, we can't spend our lifetime to a simple issue and no results (Just keeping reroll it and reroll it for nothing). We're drained.

#1931632: [META] Make CORE compatible with jQuery native-API selector
I thought it's a week of work. But in Drupal is few years and no results. Is it just because Drupal has no JS testcases? I doubt it honestly.

Second: Introduce a better Design Pattern for JS.

Third: I think it's good to pick a super lightweight client-side script and implement the Model part first.

Wim Leers’s picture

the biggest problem now is "Missing a Model Data Layer in Drupal's JS". Therefore, we can't redirect the flow to other client-side system easily.

This is exactly what I've been thinking lately! You have to enable the REST module, then modify rest.settings.yml, then grant permissions, then write lots of code that deals with D8's REST API peculiarities (Drupalisms). That's a huge, huge obstacle.

I think Drupal core should ship with a core/backbone-drupal-models asset library. If you depend on that library, you'll be able to do this in your JS code:

// Fetch a node.
var nodeEntity = new Drupal.Backbone.Models.Node({id: 5});
nodeEntity.fetch();

// Now update it.
nodeEntity.set({title: 'Hi Dries'});
nodeEntity.save();

That'd drastically reduce the barrier to entry. You won't need to know about the CSRF token you have to request and send, or the exact routes to talk to, or which fields of an entity type should not be sent on PATCH requests, or the fact that you MUST specify the bundle for entity types that have bundles even though that kind of violates the previous point, or the fact that you have to remember to set the Content-Type request header, or …

The vast majority of those small obstacles then disappear. Yes, it'll be Backbone. But contrib could provide it for other JS libs/frameworks too.

IMO this would hugely reduce the number of steps you need to perform before you can even start to experiment.

Wim Leers’s picture

#2542050: Toolbar implementation creates super annoying re-rendering.
It's using Backbone. However, I think it's misused this framework in many way (I called it Drupal-Backbone-Way). It didn't fully use Backend Model for data.

I agree. Jesse Beach first brought the Toolbar to core together with others (#1137920: Fix toolbar on small screen sizes and redesign toolbar for desktop), but the result was extremely painful to debug & maintain. Then we had Backbone in core and she refactored it on top of Backbone (#1860434: Refactor the Toolbar JavaScript to use Backbone; fix several poorly functioning behaviors), which was a vast improvement (consider the issue summary there: After several months of use, it has become evident that the Toolbar JavaScript code is unstable and buggy in several places. — quite telling!).
But we all know how annoying the delay is between the page showing up and the toolbar being rendered (#2542050: Toolbar implementation creates super annoying re-rendering.). So clearly, there is still a lot left to be desired. Unfortunately, Jesse is not around anymore, if she were, I'm sure she'd have taken up improving this a long time ago.
We used to have much bigger problems before getting Drupal 8 out, but now that it is out, I think this has become a very important problem to address. I think nobody would oppose a refactor (which for some parts of it could amount to a rewrite) of the Toolbar's JS to make it behave better.

almaudoh’s picture

the biggest problem now is "Missing a Model Data Layer in Drupal's JS".

+1000. To me this is exactly the crux of the matter. I was hoping this is what backbone would bring to D8. Like @wimleers #8 outlines specific examples. I would favour something lightweight that allows easy and proper model definition in js.

jordan8037310’s picture

+1 to a robust model data layer.

Exposing entities and standardizing the way we surface interaction and content relationships within Drupal to a model data layer sounds like a sane first-step towards exposing OO data in a rich and predictable format, not just for applications to consume, but also for surfacing contextual relationships users, organizations, and a wider-variety of platforms.

For consideration, Snowplow demonstrates the need for a "Universal Event Grammar" or "Lego Data Layer" which allows analysts to make sane interpretations of user interactions.

To me, exposing Drupal's entities to a standardized data layer is the first step towards enabling integrated systems safely interface with Drupal in a consistent and dependable way—be those systems applications (JS, etc), analytics platforms (Snowplow, Google Tag Manager, etc), or quite simply the minds of any developer who is not acclimated to Drupalisms.

yoroy’s picture

Lets collect some examples of interactions that would benefit from a smarter and more capable frontend: #2675320: A list of interactions that could benefit from having a smart frontend framework

SKAUGHT’s picture

I often think one of the issues is people don't know how to use drupal's ajax system as it is. Poor documentation is certainly a problem for that (general performance of the ajax system is second to that). Mixing in another JS tool for the sake of doing so or saying "we're using that too!" isn't a good idea. Personally, I find that's happening too much with Angular right now.

As for finding a way to judge and categorize all the JS tools that 'could be used'. Both the strength and weakness of them. With attention to their release stability and clarification of the API's. Choose solid tools, not just cool ones! please!

sorry, rant comes in relation to: https://www.drupal.org/news/turning-drupal-outside-in

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.