Comes up periodically that people want to alter the order of behaviors being run or only run a few of them. Instead of modifying Drupal.behaviors
object we should have a way of controlling that explicitly (came up in #2362637: Editor.js attach/detach doesn't pass context all the way down). Having this would mean that the behavior system is justified and Drupal can't use events to do it's thing, see #1446166-39: Use JS events instead of Drupal.behaviors.
Introducing a new parameter, behaviorList
, and a new function Drupal.behaviorList
.
Drupal.attachBehaviors(document, drupalSettings, ['AJAX', 'editor', 'formUpdated', 'escapeAdmin']);
// Override default behavior ordering
Drupal.behaviorList = function (event, trigger) { return myCustomOrderedBehaviorsArray; };
Same for Drupal.detachBehaviors
. behaviorList
defaults to the whole list of behaviors. This can also be used to alter the order in which behaviors are run.
Beta phase evaluation
@TODO
Issue category | Task |
---|---|
Issue priority | Normal |
Prioritized changes |
Main goal of issue is adding flexibility to drupal behaviors management.
|
Disruption | API addition, no API break. |
Comment | File | Size | Author |
---|---|---|---|
#49 | 2367655-nr-bot.txt | 165 bytes | needs-review-queue-bot |
#39 | core-js-behaviorList-2367655-39.patch | 5.78 KB | nod_ |
Comments
Comment #1
nod_Umm actually having a
Drupal.behaviorList
function would be better, it can be overriden by contrib.Comment #2
nod_Not quite ready yet, doc probably needs work.
Comment #3
nod_Reroll
This would be a solution for the weight issue #1945262: Replace custom weights with dependencies in library declarations; introduce "before" and "after" for conditional ordering, make the after/before in the JS, not in the file ordering.
Comment #4
lauriiiI tested this manually and it does actually work! Also the code changes looks clean. Thanks nod_ for your hero coding on this issue!!
Comment #5
Wim LeersIs this
{Something}
stuff now the norm/standard/rule?Comment #6
nod_Will be, yes. Once I get the the courage to work on #2182153: [Meta] Document Drupal JavaScript using JSDoc.
Comment #7
nod_Comment #8
Wim LeersThanks for both #6 and #7!
Comment #12
nod_Reroll after eslint update patch.
Comment #14
nod_Comment #16
lauriiiLooks good!
Comment #19
nod_Comment #20
alexpottThis issue is a normal task so we need to outline how it fits within the allowable Drupal 8 beta criteria. Can someone add Drupal 8 beta phase evaluation template to the issue summary.
I've confirmed that no existing usages call attachBehaviors or detachBehaviors with an additional argument.
Comment #21
Manuel Garcia CreditAttribution: Manuel Garcia commentedPasted in the template.
Comment #22
nod_Comment #23
alexpottI'm not really sure how this issue passes the beta evaluation :( Also we need a CR if this is to be considered for commit anyway.
Going to discuss with the other committers.
Comment #24
nod_At least I want
Drupal.behaviorList
function exposed so we can override it when we need to mess with behavior initialization. The behaviorList parameter is welcome but not required.Only reason it didn't go through earlier was lack of review, it was ready 6 months ago despite my comment in #2, the additional changes needed to end up with #12 are cosmetic. I'll do a CR this afternoon.
Comment #25
nod_Moving to 8.1.x
Comment #29
Wim LeersWe can now write JS tests.
Comment #38
lucasantunes CreditAttribution: lucasantunes commentedI'm sorry, but I don't get why don't we have events dispatched for every module attach/detach.
It would be fairly easy to run my code if I need module X to attach first, something like
Comment #39
nod_Reroll :p
The issue is not to react on attach/detach, with what you're proposing the issue would be to change the order which the detach events are called for each "module", how do you make sure the "contextual" module detach before the "toolbar" module for example?
Using events means replacing the line
behaviors[behaviorName].attach(context, settings);
with something like$(context).trigger(`d-${behaviorName}-attach`, [context, settings]);
and change all the behavior code ever written to use listeners. That doesn't solve the ordering problem I raised in the IS.I still think it's a good idea even if I'm not entirely sold on the finer details of this implementation anymore but it's a quick reroll so why not.
Comment #40
nod_Comment #41
lauriiiDo we have any potential use cases for this? This is probably not something that many contrib projects would want to do but the current implementation would make it difficult for multiple contrib projects to override the behavior list. I'm also wondering what are the use cases for passing the behavior list for the when attaching behaviors? I believe you explained all of this to me ~6 years ago but unfortunately I can't recall any of that.
Comment #42
andypostThe only issue I recall is #2905036: Lower weight of classList library to optimize aggregation
Comment #43
nod_@lauriii 2020, meet @lauriii 2015: #2474019: Implement before and after behavior ordering :p
Thinking about it this issue is not really necessary, if we really need Proxy can be used for that. Doesn't work on IE11 but at this point you're better off with overriding attachbehaviors.
Like wim said in #2474019-2: Implement before and after behavior ordering would be best to take care of this at the library level.
Comment #44
lucasantunes CreditAttribution: lucasantunes commented@nod_ Yeah, I think my question maybe should be another issue hehe... Now I got this issue right. Sorry about that!
I think the proposal is great, though. It's something I've been wanting for a long time, and will definitely be of great use. We often needed to make some ugly workarounds using either setTimeout/setInterval or a MutationObserver simply because we couldn't avoid a behavior being run before ours.
Patch looks good to me!
Comment #49
needs-review-queue-bot CreditAttribution: needs-review-queue-bot as a volunteer commentedThe Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.