Fix FormTokenField rendering #14819

tfrommen · 2019-04-04T12:08:34Z

Description

The FormTokenField component takes both the list of values to select from and the list of currently selected values as props.

However, updating and rendering the component only relies on user interaction (i.e., changing what is in the input). Any changes to either the selectable values or the selected values is ignored.

This results in bad UX in case the values are fetched (asynchronously). The behavior is that you would enter something, WordPress goes and fetches the results, passes them to the component, ... and nothing. Rendering will only happen on the next change in the input.

(By the way, this is the exact situation with any non-hierarchical taxonomy input, for example, Tags.)

This PR fixes that logic, and updates the selection if either of the selectable or selected values changes.

How has this been tested?

Steps to reproduce:

A real-life use case is the Tags panel input. Assuming you have a post tag "test". Typing te into the input will kick off an according API call, and you get your response back. But nothing happens. At least not visually. The component has received the updated prop, but only on a third keystroke, say typing "s" to have "tes", you see the result.

Screenshots

Types of changes

Fix logic in rendering/reselection.

Checklist:

My code is tested.
My code follows the WordPress code style.
My code follows the accessibility standards.
My code has proper inline documentation.
I've included developer documentation if appropriate.

tfrommen · 2019-04-10T08:59:18Z

@gziolo I just added a small unit test ensuring that changing the suggestions prop actually updates/re-renders the suggestions.

With the code in this branch, the new test passes. However, if one were to change this:

gutenberg/packages/components/src/form-token-field/index.js

Lines 61 to 64 in ca3e521

    
           const suggestionsDidUpdate = suggestions !== prevProps.suggestions; 
        
           if ( suggestionsDidUpdate || value !== prevProps.value ) { 
        
           	this.updateSuggestions( suggestionsDidUpdate ); 
        
           }

to this:

    const suggestionsDidUpdate = suggestions !== prevProps.suggestions; 
    // if ( suggestionsDidUpdate || value !== prevProps.value ) { 
    if ( value !== prevProps.value ) { 
        this.updateSuggestions( suggestionsDidUpdate ); 
    }

the new test fails, which is exactly what we want here.

aduth · 2019-04-29T18:06:17Z

Can you include some testing instructions here for a reviewer to know how to verify the intended changes?

tfrommen · 2019-04-29T18:38:39Z

@aduth in essence, this PR updates the rendered suggestions in case a depended-upon prop, suggestions, changes. So, manually changing the suggestions prop will not re-render the suggestions list, but it should.

A real-life use case is the Tags panel input. Assuming you have a post tag "test". Typing te into the input will kick off an according API call, and you get your response back. But nothing happens. At least not visually. The component has received the updated prop, but only on a third keystroke, say typing "s" to have "tes", you see the result.

Not sure this helps...?

aduth · 2019-04-29T19:06:22Z

A real-life use case is the Tags panel input. Assuming you have a post tag "test". Typing te into the input will kick off an according API call, and you get your response back. But nothing happens. At least not visually. The component has received the updated prop, but only on a third keystroke, say typing "s" to have "tes", you see the result.

That helps clarify, thanks. Including this sort of steps in the initial comment a reviewer knows what to be looking for (like a bug report's "Steps to Reproduce").

tfrommen · 2019-05-19T19:20:56Z

@aduth @gziolo this is waiting for quite some time now, so I was wondering if there's anything (for me) to do here? 🙂

I hope to have explained the issue, the fix and steps to test/reproduce, and there are some unit tests.
Should I expand on any of these, or is there something else missing or not quite right yet?

Thanks!

aduth · 2019-05-21T18:41:40Z

packages/components/src/form-token-field/index.js

 		// Make sure to focus the input when the isActive state is true.
 		if ( this.state.isActive && ! this.input.hasFocus() ) {
 			this.input.focus();
 		}
+
+		const { suggestions, value } = this.props;
+		const suggestionsDidUpdate = suggestions !== prevProps.suggestions;


This probably updates more than you're expecting it to, at least based on the shape of suggestions being an array, and the array being generated as a new value on each render.

Essentially, it comes down to:

const a = [ 'foo' ]; const b = [ 'foo' ]; console.log( a === b ); // false

Related: http://adripofjavascript.com/blog/drips/object-equality-in-javascript.html

At least in how this is used by FlatTermSelector, the array is a result of Array#map, so would be a new value on each render:

gutenberg/packages/editor/src/components/post-taxonomies/flat-term-selector.js

Line 211 in 8960509

const termNames = availableTerms.map( ( term ) => term.name );

gutenberg/packages/editor/src/components/post-taxonomies/flat-term-selector.js

Line 229 in 8960509

suggestions={ termNames }

The map() method creates a new array with the results of calling a provided function on every element in the calling array.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/map

Options:

Accept the fact that it renders more than we expect it to, but that it might benefit from some reuse if the references stay the same

Abandon any attempt to avoid updating and always update suggestions

Consider instead equality of members for sameness (@wordpress/is-shallow-equal). There is a small performance overhead to this, if it's worth considering the costliness vs. updateSuggestions (or whether updateSuggestions must only be called when in-fact it changes)

Hey @aduth - thanks for the feedback, and sorry for the super late reply. I missed this comment (and only read the review one further down). 🤦‍♂

You are absolutely right, and I now implemented isShallowEqual to compare suggestions. 👍

Is this PR all good now? (Build and tests are still pasing.) 🙂

aduth · 2019-05-21T18:45:57Z

Apologies for the delay in revisiting this. There's quite a backlog for reviews. In case you find yourself in a similar situation, please feel welcomed to review other pull requests while waiting to help contribute to a lower review turnaround.

aduth

Thanks for the patience, and for the fix! This looks good to me 👍

Aside: I found it easiest to verify the fix using Chrome's built-in network throttling options.

aduth · 2019-07-31T13:35:18Z

packages/components/src/form-token-field/index.js

-			selectedSuggestionScroll: false,
-			isExpanded: false,
-		} );
+		this.setState( { incompleteTokenValue: tokenValue }, this.updateSuggestions );


Technically we could avoid this.updateSuggestions as the callback here and consolidate instead to componentDidUpdate (which can also detect the state change).

* Fix rendering/reselection upon prop changes * Add unit test * Use isShallowEqual to compare suggestions

sgrund14 · 2020-04-08T19:24:12Z

for whatever reason I'm not getting this behavior when importing from @wordpress/components @9.3.0. the asynchronous fetch happens, updates the suggestions being passed into FormTokenField, but then... the suggestion list doesn't expand until I type in the input again!

but the really strange thing is, if I copy over the source code from node_modules into my own component, this new behavior is working. any idea what might be happening @aduth @tfrommen?

aduth · 2020-04-13T14:10:37Z

Hi @sgrund14 , it's been some time since I looked at this pull request, so I can't exactly recall what the problem might be based on what you describe. Regarding the difference from node_modules, one thing I could think of is if your first scenario is referring to an older version of the package, specifically one shipped with WordPress (and perhaps an older version of WordPress). These scripts can lag behind the versions which are published to NPM, so that could potentially explain a difference you're seeing. It depends if your code is referencing the globals (wp.components), which is also configured in most of the default developer tooling offered through @wordpress/scripts (in case you're using it).

I'd suggest if you suspect there to be a bug in the component, to create a new issue, since it'll be easier to follow-up on than to continue the discussion in this old pull request.

sgrund14 · 2020-04-13T21:46:15Z

I'm not referencing the globals, but I'll open up a new issue. Thanks @aduth :)

Fix rendering/reselection upon prop changes

2aefd9c

tfrommen requested review from aduth, ajitbohra, chrisvanpatten, gziolo, jorgefilipecosta, noisysocks, talldan and youknowriad as code owners April 4, 2019 12:08

gziolo added [Type] Enhancement A suggestion for improvement. [Feature] UI Components Impacts or related to the UI component system Good First Review A PR that's suitable for someone looking to contribute for the first time by reviewing code labels Apr 5, 2019

Add unit test

ca3e521

tfrommen added the [Package] Components /packages/components label May 19, 2019

aduth reviewed May 21, 2019

View reviewed changes

Use isShallowEqual to compare suggestions

15f476a

aduth approved these changes Jul 31, 2019

View reviewed changes

aduth merged commit f380cc4 into WordPress:master Jul 31, 2019

tfrommen deleted the fix-form-token-field branch August 5, 2019 07:55

youknowriad added this to the Gutenberg 6.3 milestone Aug 9, 2019

gziolo pushed a commit that referenced this pull request Aug 29, 2019

Fix FormTokenField rendering (#14819)

15e47af

* Fix rendering/reselection upon prop changes * Add unit test * Use isShallowEqual to compare suggestions

gziolo pushed a commit that referenced this pull request Aug 29, 2019

Fix FormTokenField rendering (#14819)

9ff7b52

* Fix rendering/reselection upon prop changes * Add unit test * Use isShallowEqual to compare suggestions

sgrund14 mentioned this pull request Apr 13, 2020

@wordpress/components referencing old version of FormTokenField #21568

Closed

snyk-io bot mentioned this pull request Aug 13, 2024

[Snyk] Upgrade @wordpress/element from 5.28.0 to 6.3.0 Playgirlkaybraz11/wp-xeet#8

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix FormTokenField rendering #14819

Fix FormTokenField rendering #14819

tfrommen commented Apr 4, 2019 •

edited by gziolo

Loading

tfrommen commented Apr 10, 2019 •

edited

Loading

aduth commented Apr 29, 2019

tfrommen commented Apr 29, 2019 •

edited

Loading

aduth commented Apr 29, 2019

tfrommen commented May 19, 2019

aduth May 21, 2019

tfrommen Jul 18, 2019

aduth commented May 21, 2019

aduth left a comment

aduth Jul 31, 2019

sgrund14 commented Apr 8, 2020

aduth commented Apr 13, 2020

sgrund14 commented Apr 13, 2020

Fix FormTokenField rendering #14819

Fix FormTokenField rendering #14819

Conversation

tfrommen commented Apr 4, 2019 • edited by gziolo Loading

Description

How has this been tested?

Screenshots

Types of changes

Checklist:

tfrommen commented Apr 10, 2019 • edited Loading

aduth commented Apr 29, 2019

tfrommen commented Apr 29, 2019 • edited Loading

aduth commented Apr 29, 2019

tfrommen commented May 19, 2019

aduth May 21, 2019

Choose a reason for hiding this comment

tfrommen Jul 18, 2019

Choose a reason for hiding this comment

aduth commented May 21, 2019

aduth left a comment

Choose a reason for hiding this comment

aduth Jul 31, 2019

Choose a reason for hiding this comment

sgrund14 commented Apr 8, 2020

aduth commented Apr 13, 2020

sgrund14 commented Apr 13, 2020

tfrommen commented Apr 4, 2019 •

edited by gziolo

Loading

tfrommen commented Apr 10, 2019 •

edited

Loading

tfrommen commented Apr 29, 2019 •

edited

Loading