Hooks: explore making namespace optional and adding it to hookName using dot notation, similar to jQuery

[adamsilverstein]

As per the recent core JavaScript chat (https://wordpress.slack.com/archives/C5UNMSU4R/p1523366105000538) it would be worth exploring the possibility of removing the namespace parameter and instead making it an optional part of the hookName parameter, added via dot notation in the form hookName.vendor/plugin/function.

This would better match the function signature of our existing PHP filters and prevent the headache of forgetting the namespace parameter.

[rmccue]

FWIW, we made it mandatory for the REST API specifically so that it was required. The intention was to use the API design to shape user behaviour in a very intentional way.

However, part of this is because REST APIs are very static, and we can't do as much forwards-compatibility trickery as you can in a dynamic setting like PHP or JS.

Whether it's appropriate in JS I don't have an opinion on, just noting that "the headache of forgetting the namespace parameter" was something we intentionally designed there. :)

[adamsilverstein]

@rmccue I tend to agree that requiring the namespace parameter may be useful in shaping developer practices. I'm not yet convinced removing it makes sense, I added this PR to explore the possibility.

One option here would be to still require the namespace, while still moving it to the hook parameter with dot-notation (removing it as a separate parameter). Developers building Gutenberg pointed out that the discrepancy between the parameters for PHP vs JS filters (JS added the namespace parameter before the callback to "name" it) is a continual source of friction/confusion.

Another issue raised recently about the addition of the new parameter is we risk breaking existing uses of wp.hooks - while not officially in core, some plugins have taken advantages of Carl Danley's original library, including ACF which reported breaking in part due to the parameter changes.

[ntwb]

Issue moved to WordPress/gutenberg #7802 via ZenHub