Add basic API for registering callbacks on attributes #336
Conversation
This adds a basic method for registering a callback function on an attribute field when registering UI for a shortcode. If the attribute `callback` is defined on a field and maps to the name of a valid javascript function, that function will be called on rendering the shortcode UI and on any changes to that attribute field. The value of *this* in the callback function will tbe the array of view models representing all of the attribute input field views, and the function receives two arguments: the changed value, and the collection of model attributes.
|
I would love to get people's feedback on this as a potential solution to the problem of dynamically updating or showing/hiding fields based on the value of another field. I think the function signature of the callback function probably needs some thought as to possible use cases - what information would make writing callback functions easier? - but this is the general approach I think would work for this. |
Seems like a lot of code to register a callback function -_- Not sure how we'd do any better though, given it's a PHP API to register some frontend functionality. Rather than add a |
I actually like that concept a lot. There's no reason to have to name a callback function in the PHP array that registers the shortcode UI. Every update could trigger a named hook, like |
|
Some conversation with @azaozz https://wordpress.slack.com/archives/core/p1433109163000965 |
This uses a version of WP-JS-Hooks to provide a set of actions that update callback functions can be hooked onto, rather than the rather clumsy approach of having to register a function name in the PHP array used to register the shortcode UI. Code for the EventManager was taken basically wholesale from https://github.com/carldanley/WP-JS-Hooks , but namespaced to `wp.shortcodeUi.hooks` rather than `wp.hooks`, so as not to conflict with the set of hooks that may land in core, in case there are slight differences in the final API.
|
Yeah, that pretty much jived with what I saw looking into those libraries. I used a slightly modified version of https://github.com/carldanley/WP-JS-Hooks, and registering a listener function makes a lot more sense now. Updated the branch in Image Shortcake that uses this; it hasn't changed much, but it's nice that javascript functions don't have to declare themselves in PHP anymore. I'm not sure what the best way of including this code in the plugin is, though. I ended up including the WP Hooks EventManager class in the |
What about:
Would this address your reservations? |
|
Yeah, that's pretty much what I did here. The process is kind of a mess, but I couldn't come up with anything better. I considered forking the |
|
Cool. If you'd like to update then, we can land it. |
* Removed accidental `console.log`. * Changed the hooks' namespace from `wp.shortcodeUi` to `wp.shortcake`. Avoiding unnecessaryCamelCasing leads to greaterHappinessAllAround. * Included a minified version of the wp-js-hooks file. * Moved the wp-js-hooks script into its own directory for better organizational structure.
|
Nice! Ready for final review, I think... |
Originally I tried including wp-hooks as a requireJS module. That didn't make any sense because it needs to be in the global namespace. So, removed it. Also, fixed the namespace in the action call from edit-attribute field (the namespace registration was updated from `shortcodeUi` to `shortcake` in the last commit, but editAttributeField was still trying to call `wp.shortcodeUi.hooks.addAction`)
inc/class-shortcode-ui.php
Outdated
There was a problem hiding this comment.
Can we enqueue as shortcode-ui-js-hooks to avoid collisions?
There was a problem hiding this comment.
And what is that version?
There was a problem hiding this comment.
Can we enqueue as shortcode-ui-js-hooks to avoid collisions?
Yeah, makes more sense. I'll update.
And what is that version?
The datetime I added that line. I guess that doesn't clear anything up at all - the chance that someone who updated the file would also remember to update the version number here is slim to none. Maybe better to just use the plugin version number like aberything else does?
There was a problem hiding this comment.
Can we just use 2015-03-19 to more clearly indicate it's a date?
There was a problem hiding this comment.
Sure. What date does that refer to? The patch file I was building off of is from 2014-03-08.
There was a problem hiding this comment.
You should use the latest from the repo: https://github.com/carldanley/WP-JS-Hooks
There was a problem hiding this comment.
Ah, yeah, that makes sense. I've updated that, and clarified in the file header comments.
|
Couple small questions. |
The latest version of this interface doesn't require a callback function. It doesn't need to be referenced in the specs anymore.
Avoids potential naming conflict with core functionality.
Updates the wp-hooks event manager to the version in the Github repo. Uses the last modified date of the src file in the repo as the version number for script enqueueing.
Add basic API for registering callbacks on attributes
This adds a basic method for registering a callback function on an
attribute field when registering UI for a shortcode. If the attribute
callbackis defined on a field and maps to the name of a validjavascript function, that function will be called on rendering the
shortcode UI and on any changes to that attribute field.
The value of this in the callback function will be the array of view
models representing all of the attribute input field views, and the
function receives two arguments: the changed value, and the collection
of model attributes.
See #316 and #333.
An example of a callback function that uses this API is in wp-shortcake/image-shortcake#36