Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: Simplify list and text WHERE validation #8575

Merged
merged 2 commits into from
Sep 20, 2024

Conversation

johnnesky
Copy link
Member

@johnnesky johnnesky commented Sep 14, 2024

The basics

The details

Resolves

Fixes #8556

Proposed Changes

I modified the following block type definitions:

  • lists_getIndex
  • lists_setIndex
  • lists_getSublist
  • text_getSubstring

Each of these had an input called AT with an attached field called WHERE. The input and its attached field were sometimes removed and recreated in response to the field's validator. This PR instead attaches the field to a separate dummy input, such that the field does not need to be recreated every time the input is recreated.

Reason for Changes

Edits to the field did not always fire a BlockChange event. In particular, if the user is trying to change the field's value to its default value, but the field gets recreated, then the recreated field will already have the default value and thus no change is detected.

Test Coverage

All existing tests pass. Manual testing confirms that BlockChange events are fired as expected.

Additional Information

I can't prove that nobody is depending on the specific hierarchy of inputs and fields in these blocks, although I preserved the existing names of the inputs and fields. I also added new names for new dummy inputs in some cases (so that other inputs could be moved adjacent to them). Should this be considered a breaking change?

Also, there's a bug when undoing/redoing edits to the WHERE field while a child block is already attached to the AT input. Changing the field's value can replace the AT input with a dummy input, which forcibly detaches the child block, but this is not properly recorded in undo history. In particular, if you edited the field and then made additional changes, then undid all those changes and tried to redo them, the additional changes are lost. A similar bug existed before this PR, but I don't think this PR makes the bug any worse, and I suspect this PR is a prerequisite to properly fixing the bug. Possibly related to: #7950

@johnnesky johnnesky requested a review from a team as a code owner September 14, 2024 02:20
@github-actions github-actions bot added PR: fix Fixes a bug and removed PR: fix Fixes a bug labels Sep 14, 2024
blocks/lists.ts Outdated
menu.setValidator(
/**
* @param value The input value.
* @returns Null if the field has been replaced; otherwise undefined.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The validator appears to no longer return null; update comment accordingly?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Applies throughout

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done, thanks!

@johnnesky johnnesky merged commit 51f6dab into google:develop Sep 20, 2024
7 checks passed
@johnnesky johnnesky deleted the nesky_dropdown_change_3 branch September 20, 2024 21:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
PR: fix Fixes a bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Some FieldDropdown changes don't fire BlockChange events
2 participants