[wp-trac] [WordPress Trac] #62705: Block Bindings: Expose UI options for the source from the server (was: Block Bindings: Try fields registration on server.)

[WordPress Trac]

#62705: Block Bindings: Expose UI options for the source from the server
-----------------------------+---------------------
 Reporter:  cbravobernal     |       Owner:  (none)
     Type:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  6.8
Component:  Editor           |     Version:  6.5
 Severity:  normal           |  Resolution:
 Keywords:  has-patch        |     Focuses:
-----------------------------+---------------------
Changes (by gziolo):

 * type:  enhancement => feature request
 * component:  General => Editor
 * version:   => 6.5
 * milestone:  Awaiting Review => 6.8


Comment:

 Based on the existing prototypes, I would like to better understand what
 information does the UI need to present all options defined on the server
 and set the `args` in the block attribute's metadata?


 To start with an example included in the ticket, the `key` used in the
 source seems introduce a layer of indirection. In theory the only thing
 that the source might need to display on the frontend is the format of the
 data:


 {{{
 <!-- wp:paragraph {"metadata":{"bindings":{"content":{"source":"bbe/now-
 date","args":{"format":"D"}}}}} -->
 <p></p>
 <!-- /wp:paragraph -->
 }}}

 In effect, when the option gets selected from the Attributes UI in the
 sidebar, then the "args" need to get saved for the block. Ideally, that
 information is already provided from the server:


 {{{#!php
 <?php
 $source_ui_option_day = array(
     'args' => array(
         'format' => 'D',
     ),
 );
 }}}

 Next, we need a label to present the option in the UI:

 {{{#!php
 <?php
 $source_ui_option_day = array(
     'label' => __( 'Day of the week', 'bbe' ),
     'args'  => array(
         'format' => 'D',
     ),
 );
 }}}

 The type is used in the UI to filter the options based on the matching
 type defined for the attributes, in effect we need to provide it, too.
 Could we assume the default is `string`?

 {{{#!php
 <?php
 $source_ui_option_day = array(
     'label' => __( 'Day of the week', 'bbe' ),
     'type'  => 'string', // 'datetime` in the future?
     'args'  => array(
         'format' => 'D',
     ),
 );
 }}}

 The last missing element would be the preview of the data, in this case it
 could work pretty well:


 {{{#!php
 <?php
 $source_ui_option_day = array(
     'label'  => __( 'Day of the week', 'bbe' ),
     'type'   => 'string', // 'datetime` in the future?
     'value' => gmdate( 'D' ),
     'args'   => array(
         'format' => 'D',
     ),
 );
 }}}

 What else the UI might need?

 The last step would be the registration. Overall, we should take into
 account performance considerations as these UI options are only needed in
 the editor. There is some prior work for block variations that triggered
 refactoring in WordPress core to use a callback so the code is executed
 only when really necessary ([https://make.wordpress.org/core/2024/02/29
 /performance-improvements-for-registering-block-variations-with-callbacks/
 dev note] for context). Even in this example, we could avoid computations
 like the `gmdate` function call if the source wants to use some logic:

 {{{#!php
 <?php
 register_block_bindings_source(
     'bbe/now-date',
     array(
         'label'                          => __( 'Current date', 'bbe' ),
         'get_value_callback'  => function ( array $source_args,
 $block_instance ) {
              return gmdate( $source_args['format'] );
         },
         'ui_options_callback' => function() {
             return array(
                 array(
                     'label'  => __( 'Day of the week', 'bbe' ),
                     'type'   => 'string', // 'datetime` in the future?
                     'value' => gmdate( 'D' ),
                     'args'   => array(
                         'format' => 'D',
                     ),
                 )
             );
         }
     )
 );
 }}}

 All the nomenclature is up for debate. I wanted to share my current
 understanding of how it could work so there is an universal way for all
 sources to integrate into the existing Attributed panel in the block
 editor's sidbear.

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