Remove dependency on jQuery and drupal.js for JS settings

Personally, I never understood why Core was using $.extend, as it will always be the first to define settings. Perhaps we can have dynamically loaded settings to define them in a way that doesn't require $.extend, but does that mean all settings should be defined in this way?

+++ b/core/misc/drupal.jsundefined
@@ -1,14 +1,17 @@
+// Populate Drupal.settings with the drupalSettings variable.
+Drupal.settings = drupalSettings;

I'm confused, why is this still being copied over to Drupal.settings, or why does it seem like everything is using drupalSettings anyway? seems like one of these 2 should be irrelevant...

That's what change notifications are for.
Let's keep confusing code out of Drupal 8 :)

ah, that was my best guess. If we keep it around, wouldn't that sorta defeat the purpose? And it should probably get an explanatory comment line or something.

Discard my comment about "defeats the purpose", was being silly, as usual.

I see where you're getting at, I'm already very glad to get rid of this awkward extend.

I suppose this needs a change notification though?

Sure, I just add a record on http://drupal.org/list-changes/drupal right?

But I guess it needs to be committed first, no?

Added change record information to the summary.

Added change record to the issue summary.

This no longer applies, quick re-roll?

Looks good to me!

Thanks! Committed/pushed to 8.x.

How are we now then supposed to deal with dynamically loaded settings? (e.g. an AJAX command adds some HTML which comes with an attached JS behavior, which comes with its own settings.) AFAICT, it continues to work the same way, i.e. it still uses $.extend, it's just that we don't need it anymore for the *initial* Drupal JS settings?

Okay. We have a change record, which links here, and the question has been answered here. That's good :)

*However*, ajax.js still updates Drupal.settings, not drupalSettings. Shouldn't we try to get everything to move over to use drupalSettings? That will be addressed in follow-up issues, I presume?

Agreed! :)

I don't quite get why we had to introduce a new global, instead of simply declaring Drupal.settings without jQuery?

<script>
var Drupal = Drupal || {};
Drupal.settings = Drupal.settings || {.......};
</script>

There.

It's also noteworthy that this overall change (regardless of #34) has a few implications:

1) Settings MUST NOT be output twice on the page; e.g., 'scope' => 'footer'. The former $.extend() took care of properly merging multiple instances. The current JS processing and rendering for JS settings does not take that into account.

2) Likewise, an Ajax request MUST NOT return bare/plain drupalSettings/Drupal.settings, but only ever Ajax settings commands. The current Ajax framework does not ensure that.

3) There is generally no way to extend or enhance settings after Drupal settings have been rendered/output. This was previously possible through inline JS and other means.

I'm sorry, but that terribly sounds like a second-guessed reasoning ;)

If we get to that level, then I will happily hold against that: Polluting the global namespace with variables is bad practice.

The original intention and scope of this issue was to remove the dependency on jQuery and drupal.js for JS settings.

+++ b/core/modules/simpletest/lib/Drupal/simpletest/WebTestBase.php
@@ -2019,7 +2019,7 @@ protected function drupalSetContent($content, $url = 'internal:') {
+    if (preg_match('/jQuery\.extend\(Drupal\.settings, (.*?)\);/', $content, $matches)) {
       $this->drupalSettings = drupal_json_decode($matches[1]);

Sorry, forgot this one.

Righto, as I already mentioned, none of the issues listed in #34 are about drupalSettings vs. Drupal.settings, because they share the same semantics, since only the variable name differs.

What strikes me with drupalSettings is that 1) it looks awkward both in PHP and JS, 2) it pollutes the global namespace for no good reason, 3) it was and is unnecessary for the actual desired change, as the patch proves.

To be honest, I don't care where it lives right now. Until the Drupal namespace looks more like a library, it doesn't really matter all that much. We will probably need to do this at some point, though.

I see this patch as a stone in the path to a larger architectural change, namely an AMD structure. The details might change in the coming months but it's a good first step. My comments are really more for us to consider in those changes we will continue to make.

I'd really love to see us using an extend pattern here. It's far more resilient. We'll need some basic utilities that are available cross-module e.g. extend(). We can't expect every module to implement their own utils. One of the value propositions of using Drupal is that lots of basic, foundational code has been written for you and is available to leverage. Is the plan to require modules to require the drupal.js file or does drupal.js just disappear? Do we plan to load no JavaScript file in vanilla core that contains common utilities but instead repeatedly reimplement these utils in each module or misc JS file as needed? I can think of a few that would be nice to have

• extend
• clone
• debounce
• map

Certainly there are more. It would probably be better to just to use underscore really.

I understand the intent to rid ourselves of any Drupal JS object in the global namespace. But if drupalSettings is really unique to its context, why not just call it settings? As @sun mentions in #39, the semantics are the same in the current drupalSettings vs. Drupal.settings. Do we need a pseudo-namespaced variable for backwards compatibility?

But if drupalSettings is really unique to its context, why not just call it settings?

I have troubles to understand what you mean, but if you mean a global window.settings object with this, then that won't fly at all, since it breaks all concepts of embeddable applications that exist. The rule of thumb is to presume that Drupal is not the only application that is involved in producing a final page output (neither on the PHP side, nor on the JS side). Thus, there can be a poorly architected app/script next to Drupal that expects its options in window.settings, but 1) Drupal is not poorly designed, and 2) Drupal is able to co-exist and play nice with other libraries by properly namespacing its own stuff.

(Admittedly, the PHP side of things is not that clean yet, so it's only by coincidence that you may be able to embed Drupal into another PHP application. But that's a major bug, and not to be understood for a given.)