[wp-trac] [WordPress Trac] #27355: Customizer: Add framework for selective refresh (partial preview refreshes)

[WordPress Trac]

#27355: Customizer: Add framework for selective refresh (partial preview refreshes)
----------------------------+--------------------------
 Reporter:  westonruter     |       Owner:  westonruter
     Type:  task (blessed)  |      Status:  assigned
 Priority:  normal          |   Milestone:  4.5
Component:  Customize       |     Version:  3.4
 Severity:  normal          |  Resolution:
 Keywords:  needs-patch     |     Focuses:  javascript
----------------------------+--------------------------

Comment (by westonruter):

 Replying to [comment:51 rabmalin]:
 > Great. Nice work done. Following things came to my mind after testing
 `feature/framework` branch of the repo.
 >
 > * `add_theme_support` declaration could be omitted. I would like to go
 with Nick in this. If `transport` is `partialRefresh` then framework
 should automatically apply that method.
 > * Separate line for `selector` assignment in separate line could be
 simplified by passing it as arguments in `add_setting`.

 Note that the `selector` won't have to be defined outside of the args
 passed into `WP_Customize_Setting` once a core merge happens because at
 that time it will be a core property defined on the class, and so it will
 recognized automatically.

 > * When I tested using `partialRefresh`, I noticed two request on every
 change. One was AJAX request and another was request for whole site. I
 guess that was for full page refresh. May be this is a bug.
 > * It would be great to some kind of notice if `transport` is set
 `partialRefresh` and `selector` is not set.

 I've just updated the patch with a round of improvements, including most
 of the feedback so far: https://github.com/xwp/wp-customize-partial-
 refresh/pull/17#issuecomment-172401750

 > OK, pushed [https://github.com/xwp/wp-customize-partial-
 refresh/commit/93765c4d83efc6214702fb4c74952cc421fd7a8a 93765c4] which
 introduced several changes:
 >
 > * Rename to follow selective-refresh naming.
 > * Re-use postMessage transport so that JS updates can be used for live
 approx. updates followed by selective refresh PHP-rendered data.
 > * Send selective refresh requests in batch, with Ajax response returning
 multiple partials
 > * Use `postMessage` to send selective refresh partials into preview
 > * Send message to preview when selective refresh starts so element can
 be styled.
 > * Remove spinner since selective refresh can be indicated in preview
 elements.
 > * Refresh if no elements in preview match selector.
 > * Inject selector property into Setting instances, to anticipate
 extension to `WP_Customize_Setting::json()`
 > * Let `WP_Customize_Setting::value()` be default rendered partial, using
 `WP_Customize_Setting::render()` if it exists. Supporting
 `render_callback` arg would need to be part of the Core merge.
 > * Add todos for future improvements.
 >
 > (Yes, the unit tests are now failing.)
 >
 > I also created a demo plugin (Site Title Smiles) that uses the plugin at
 the current state:
 https://gist.github.com/westonruter/a15b99bdd07e6f4aae7a
 >
 > Here's a demo video (note how text changes apply immediately via
 `postMessage` and then get upgraded to PHP-filtered text to include
 `wptexturize` and `convert_smilies` once the selective refresh gets
 applied when the Ajax request completes):
 >
 > [[Image(http://i1.ytimg.com/vi/ikW8dfaOPng/hqdefault.jpg,
 link=https://youtu.be/ikW8dfaOPng)]]
 >
 > I realized a few things when working on this patch.
 >
 > What we're doing here is basically implementing the logic to calculate
 and preview what the REST API identifies as the `rendered` properties,
 where the REST API's `raw` properties are what the Customizer actually has
 stored in the settings. There is a difference here, however, because a
 setting could be rendered in _multiple_ contexts in the preview, displayed
 in different ways in different template partials. One partial may consist
 entirely of the PHP-sanitized setting, whereas another partial may
 incorporate the setting's value as _part_ of the content. So I think our
 one-to-one mapping of settings to rendered partials is too simple and we
 need to devise a one-to-many relationship of a setting to one or more
 partials. This is somewhat what would be needed by nav menus since
 changing a `nav_menu_item` wouldn't correspond to updating a single nav
 menu item `li` in the preview: instead, it actually causes the element
 representing the nav menu to be refreshed. So all `nav_menu_item` settings
 would need to be linked to the `nav_menu`, and the API should support
 that.
 >
 > I'll also note that what this plugin now does is provide a way to easily
 see what the PHP-sanitized setting value will be. This is what the
 Customize Setting Validation plugin provides _upon save_, where the actual
 saved values get pushed back into the JS models for the settings. With
 transactions, each setting change would push the setting value into the
 transaction post via a REST API `PATCH` request, and the response there
 can include the PHP-sanitized value to make sure that the JS setting gets
 updated to reflect any PHP sanitization at the time of input.

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