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

Add editor preference to keep Link Control settings toggle open by default #47821

Open
getdave opened this issue Feb 7, 2023 · 12 comments
Open
Labels
[Feature] Link Editing Link components (LinkControl, URLInput) and integrations (RichText link formatting) [Type] Enhancement A suggestion for improvement.

Comments

@getdave
Copy link
Contributor

getdave commented Feb 7, 2023

Add an editor settings which allows the Link Control settings drawer to be open by default.


It would be great with a preference setting to where we can keep the Toggle link settings open by default.

Originally posted by @paaljoachim in #47328 (comment)

@getdave getdave added the [Feature] Link Editing Link components (LinkControl, URLInput) and integrations (RichText link formatting) label Feb 7, 2023
@draganescu
Copy link
Contributor

I think we should try and mimick the behavior of other UI that is "smart" to respond to implicit preferences - such as the block inspector in the post editor: if it's closed it remain closed when new posts are opened, and if it's open it remain open. Same should be applied for the link drawer to remain open or closed based on last state when the link UI appears.

I think adding an actual toggle in preferences is too much for this small thing.

@getdave
Copy link
Contributor Author

getdave commented Feb 7, 2023

@draganescu I like that idea. Thank you.

@paaljoachim
Copy link
Contributor

I also like that idea!

@kathrynwp kathrynwp added the [Type] Enhancement A suggestion for improvement. label Feb 7, 2023
@abhi3315
Copy link
Contributor

abhi3315 commented Feb 8, 2023

I like the idea too mentioned by @draganescu. But I have a little query, Inspector control has a button to toggle it. If I click the Inspector control button it will be in an active state and by clicking the button the second time the drawer will be closed and the button is in the inactive state.

Active
image

Inactive
image

But in the case of Link Control, the same Link button in the block toolbar has different behavior.

There is no active or inactive state of the Link button in the block toolbar. The Link Control will be shown every time I click the Link button. If the click outside (lose the focus) the Link Control will be closed.

GIF Recording 2023-02-08 at 11 31 05 PM

We can have a toggle state to this Link button too (to maintain the open/close state in the UI) but there is an Unlink button too which will be replaced with the Link button once the link/post is applied.

image

We can also separate out the Link and Unlink buttons but this might become confusing. What do you suggest?

I hope I made my point clear.

@draganescu
Copy link
Contributor

Hi @abhi3315 :) The link control does open on toolbar action, but this issue suggests only the "drawer" with the settings - which does have a toggle - to be affected. The Link popover remains unchanged.

@abhi3315
Copy link
Contributor

abhi3315 commented Feb 9, 2023

Thanks @draganescu! I was just explaining a completely different thing. 😅

I would like to contribute this issue.

@abhi3315
Copy link
Contributor

abhi3315 commented Feb 9, 2023

We might need to add a property to data store to keep the state of Link Control setting.

@getdave
Copy link
Contributor Author

getdave commented Feb 9, 2023

Hi @abhi3315. I think we will want to set an editor preference in the store.

The details are in packages/preferences/README.md.

To quote from the docs:

Use the get selector to get a preference value, and the set action to update a preference:

wp.data
	.select( 'core/preferences' )
	.get( 'namespace/editor-or-plugin-name', 'myPreferenceName' ); // 1
wp.data
	.dispatch( 'core/preferences' )
	.set( 'namespace/editor-or-plugin-name', 'myPreferenceName', 2 );
wp.data
	.select( 'core/preferences' )
	.get( 'namespace/editor-or-plugin-name', 'myPreferenceName' ); // 2

What I'm not sure about yet is

  • how we track how many times the user has clicked on the link settings toggle as they move around the editor.
  • what criteria do we use to determine when it's suitable to set the preference
  • when do we reset the preference

@draganescu Has worked with preference in the Distraction Free mode before so perhaps he has some ideas. Moreover the genesis of the idea was his so he may have a clearer view than I do on the heuristics.

@abhi3315
Copy link
Contributor

@draganescu @getdave 👋🏼

We're managing the preferences at two levels, one is edit-site and the second is edit-post.
Is there any way to know which editor is currently in use (site-editor or post-editor) so that I can get the preference accordingly?

@getdave
Copy link
Contributor Author

getdave commented Feb 10, 2023

@abhi3315 I think you don't have to scope by editor name. The scope is arbitrary. I would suggest core/editor as a way to indicate this applies to all editor types.

@abhi3315
Copy link
Contributor

@getdave I have raised a draft PR. #47989

I have added a useEffect hook to update the preference store and getting the value of it when component is mounted.

But I am facing some issue in test cases. Will you please help me out?

@abhi3315
Copy link
Contributor

The tests are failing because of the toggle setting state because in each test setting drawer is supposed to be closed by default. But now the setting drawer state of LinkControl is persistent and will depend on the previous component state.

One way to handle this is to reset the state in the preference store in each LinkControl test.

Is there anything on your mind @getdave?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Link Editing Link components (LinkControl, URLInput) and integrations (RichText link formatting) [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

5 participants