[wp-trac] [WordPress Trac] #57421: Editor: add new parameter to hook when enqueuing block assets

[WordPress Trac]

#57421: Editor: add new parameter to hook when enqueuing block assets
--------------------------+------------------------------
 Reporter:  jeherve       |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Editor        |     Version:  5.8
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  javascript
--------------------------+------------------------------

Comment (by jeherve):

 @dmsnell had some notes about this proposal in
 [https://github.com/WordPress/gutenberg/issues/46900#issuecomment-1376384170
 the related Gutenberg issue]. I've pasted his comments below and tried to
 address them.

 > it's a bit dizzying following the conversation around the various PRs
 and tickets. I don't think this is anyone's fault, but it would be helpful
 to have a header on all the related tickets listing each related
 ticket/issue/PR, a link to it, a summary of what role it plays, and an
 indication for where the canonical discussion should take part (e.g.
 "Please discuss this change at {link} to avoid duplicating in all these
 places.")

 Sorry about that! I do not have the option to edit the description of my
 Trac ticket here, but if someone does, I would recommend adding the
 following:


 ----

 This trac ticket is part 1 of a larger discussion spanning multiple
 issues, about the **potential issues plugin authors may face when
 developing blocks that rely on the `@wordpress/editor` dependency**.

 - This trac ticket is **part 1**: it suggests an option to make
 conditional asset enqueuing easier in the different block editors.
 - In **part 2**, I would like to suggest an option to declare support for
 specific editors at block registration. Discussion about this is happening
 in [https://github.com/WordPress/gutenberg/issues/46900 this Gutenberg
 issue].

 ----


 > the `admin_enqueue_scripts` hook uses the `$hook_suffix` name for its
 parameter but it looks like we're using `$hook` in this proposal. Is there
 a reason to use two names for what I think is intended to be the same
 value and serve the same purpose?

 My proposal also suggests using `$hook_suffix` (see the actual patch in
 [https://github.com/WordPress/wordpress-develop/pull/3817/files the
 attached PR]. I realize now my sample code snippet in the trac description
 above may have been a bit misleading, sorry about that.

 > doesn't seem like this is a very risky change, though if we're only
 exposing a `global` parameter, what is the value of the abstraction over
 the counter-example, where a function implementing the
 `enqueue_block_assets` hook itself pulls in the global?

 It does feel a bit cleaner to me, as it relies on the data passed with the
 hook instead of relying on the plugin authors doing their own
 implementation. It also feels consistent with how plugin authors are used
 to enqueue assets in wp-admin today, via `admin_enqueue_scripts`.

 > if we're talking about adding parameters to the hook, do we reasonably
 predict any others might come in the future? if so, does this one warrant
 being in the first/front argument position? would an associative array or
 "option bag" argument better serve it?

 That's a good question. I've only added this parameter because in my mind
 the `enqueue_block_editor_assets` hook is very similar to the
 `admin_enqueue_scripts` hook: it is used to enqueue assets inside wp-
 admin. It feels natural to have the 2 hooks taking the same parameter.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/57421#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform