Improve field selection process and speed

[bobbingwide]

Requirement

• Enable easier selection of the field to be displayed by the Field block.
• Ensure that the field can be selected when it's the first field ( and possibly only ) field for a post type
• Don't display post types which don't have any fields.
• Automatically select the post type when possible.

[bobbingwide]

Current behaviour

When the Field block is first displayed the select list for Post Type has to be populated.
The code initially displays "Wait for it..."
Then, after a while, a list of post types is displayed.
The delay is due to the REST request to load the different post types

https://s.b/wordpress/wp-json/wp/v2/types?context=edit&per_page=100&_locale=user

The results are potentially useful since they include, or could include

• labels.name
• supports.custom-fields
• taxonomies array - eg category, post_tag, letters

The post types aren't in a useful order.

When the user selects a post type then the list of fields for that post type is displayed.
If there are no supported fields then the list isn't shown.
In my s.b/wordpress development environment - where I've only just started registering fields for use with the REST API -
of the 31 different post types displayed, only 5 of them have selectable fields:

• bigram
• event
• oik-plugins
• oik_pluginversion
• oik_premiumversion

Of these bigram only has one field _seen_before.

The mapping of fields to post types is performed by the REST request

https://s.b/wordpress/wp-json/oiksb/v1/fields?_locale=user

If this request was enhanced to return not only the post type but also the label of the post type then we wouldn't need to perform the types request.

Proposed solution

Change the JavaScript so that <PostTypeSelect> uses the same store as <FieldSelect>

[bobbingwide]

Don't display post types which don't have any fields.

While investigating the solution for this I noticed several server side rendering requests where no field had been selected.
This probably won't happen in the future.

[bobbingwide]

With the changes applied the Post Types list is much shorter

But now we need to be able to deal with post types which don't have any fields to display, such as Posts.

For a new Post the Field block will display the following

In the code editor this appears as

<!-- wp:oiksb/sb-field-block {"postType":"post","fieldName":null} /-->

This is handled OK on the front end, but it's not very helpful to the user.

[bobbingwide]

There are currently 2 problems that I'm aware of

1. When the field you want to display is the first in the list you need to select another value first.
2. Some fields are not being displayed in the list. eg _oikp_dependency, which is a multiple select noderef field defined for several post types in the oik-plugins and oik-shortcodes plugins.

[bobbingwide]

Some fields are not being displayed in the list. eg _oikp_dependency, which is a multiple select noderef field defined for several post types in the oik-plugins and oik-shortcodes plugins.

This has been resolved. I needed to change the priority of an action hook implemented by oik-shortcodes so that it ran after oik-plugins action hook that registers the _oikp_dependency field. See bobbingwide/oik-shortcodes#97

[bobbingwide]

1. When the field you want to display is the first in the list you need to select another value first.

Note that currently, when the post type is first selected, the value for the fieldName becomes null.

<!-- wp:oiksb/sb-field-block {"postType":"block_example","fieldName":null} /-->

In order to fix this problem I needed to change the logic associated with loading the fields information, which is stored in the badly named content field. I needed to move the useSelect code from FieldSelect function ( field.js ) to Edit ( edit.js ).

const content = useSelect( ( select ) => {
              return select( 'oiksb/fields' ).getFields( postType );
 }, [ postType ] );

Then I had to add dummy entry to instruct the user to select the value for the fieldName.
This has a value of '' and a label of -- select --.

I also changed the Server side rendering code so that, when used in the block or site editor, the block would always display something. What's displayed depends on the value of the Show label toggle.

The logic can be further improved by not invoking server side rendering when the fieldName is either an empty string or null.

[bobbingwide]

The logic can be further improved by not invoking server side rendering when the fieldName is either an empty string or null.

The block's speed can be made much quicker by making the Server Side Rendering optional.
The slow performance of Server Side Rendering is particularly noticeable when you have several Field blocks being displayed in the Post Template of a query loop. There are lots of spinning discs.

One way to improve this is to provide a toggle labelled "Render from server".
When this is selected then the Field will be rendered from the server.
When not selected then a dummy value for the field will be rendered.

Some fields, especially virtual fields, will look much better when "Render from server" is selected.
Other fields, which are plain text, a link or a combination, will probably be OK with dummy values.

The default value of "Render from server" will be toggled off.

Could this attribute be augmented by a text icon labelled Render, which would render the value from the server even when Render from server is toggled off?