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

Move __experimentalFetchLinkSuggestions to core/data store. #32087

Closed
getdave opened this issue May 21, 2021 · 4 comments
Closed

Move __experimentalFetchLinkSuggestions to core/data store. #32087

getdave opened this issue May 21, 2021 · 4 comments
Assignees
Labels
[Feature] Link Editing Link components (LinkControl, URLInput) and integrations (RichText link formatting) [Package] Core data /packages/core-data [Type] Experimental Experimental feature or API.

Comments

@getdave
Copy link
Contributor

getdave commented May 21, 2021

Following the discussion in #31416 (comment)_ let's discuss the possibility of moving __experimentalFetchLinkSuggestions to the core-data package store.

Update: I gave this a go over here #32096.

Rationale

All of the implementations currently in use today in the various edit* packages defer theirfetchLinkSuggestions functionality to the central fetchLinkSuggestions from core-data.

Post Editor

import {
store as coreStore,
__experimentalFetchLinkSuggestions as fetchLinkSuggestions,
__experimentalFetchRemoteUrlData as fetchRemoteUrlData,
} from '@wordpress/core-data';

Widgets Editor

import { __experimentalFetchLinkSuggestions as fetchLinkSuggestions } from '@wordpress/core-data';

Site Editor

import { __experimentalFetchLinkSuggestions as fetchLinkSuggestions } from '@wordpress/core-data';

Navigation Editor

import { __experimentalFetchLinkSuggestions as fetchLinkSuggestions } from '@wordpress/core-data';

As this function fetches data from Core WP and is WordPress specific I'd like to understand why core-data would not be a good fit for this?

Indeed the README says:

Core Data is a data module intended to simplify access to and manipulation of core WordPress entities.

Possible Problems

The only issue I see is how this function is currently wired up to the <LinkControl> component which resides in @packages/block-editor.

To avoid coupling the block-editor to WordPress specific functionality it currently uses getSettings() to retrieve the __experimentalFetchLinkSuggestions function.

const { fetchSearchSuggestions } = useSelect( ( select ) => {
const { getSettings } = select( blockEditorStore );
return {
fetchSearchSuggestions: getSettings()
.__experimentalFetchLinkSuggestions,
};
}, [] );

Whilst this function is not actually available in core/block-editor it is made available in other packages (as shown above) by overloading the editor settings.

Typically what happens is something akin to the following:

import { __experimentalFetchLinkSuggestions as fetchLinkSuggestions } from '@wordpress/core-data';

function initialize( id, settings ) {
	settings.__experimentalFetchLinkSuggestions = ( search, searchOptions ) =>
		fetchLinkSuggestions( search, searchOptions, settings );

	render(
		<Layout blockEditorSettings={ settings } />, // overload here
		document.getElementById( id )
	);
}

If we make __experimentalFetchLinkSuggestions a first class API in core/data then how can we still ensure @wordpress/block-editor's <LinkControl> is not coupled to WordPress?

Similar examples

In #31464 I'm adding the ability to fetch rich meta data about an entry. I want to use this in <LinkControl> but I don't want to couple that component to a WordPress specific implementation.

Again, we need a way to make calls to REST API endpoints but still allow them to be overloaded on a per editor basis.

cc @gwwar @adamziel @youknowriad @gziolo

@getdave getdave self-assigned this May 21, 2021
@getdave getdave added [Feature] Link Editing Link components (LinkControl, URLInput) and integrations (RichText link formatting) [Package] Core data /packages/core-data [Type] Experimental Experimental feature or API. labels May 21, 2021
@adamziel
Copy link
Contributor

We're in a weird situation where we have a package with "generic" blocks but no go-to procedure to integrate them with WP. It seems like there we don't need any super-specific integrations at the moment and searchEntities (previously __experimentalFetchLinkSuggestions) nicely fits my mental model of core-data. 👍 from me.

@getdave
Copy link
Contributor Author

getdave commented Jun 21, 2021

Let's leave this for now. It's here if we ever need to circle back.

@getdave getdave closed this as completed Jun 21, 2021
@kaizen-lazevedo
Copy link

Is there anyway of using the LinkControl outside the block editor due to the usage of __experimentalFetchLinkSuggestions from the Settings ? I'd like to use the LinkControl on a custom admin page (wp_admin?page=my_custom_page) and used the following Javascript code:

wp.element.render(
    wp.element.createElement( wp.blockEditor.__experimentalLinkControl,{
        onChange:function(value){console. Debug(value);},
        showSuggestions:true,
        value:{url:'test'}
    } ),
    document.getElementById( 'my_linkcontrol' )
);

The LinkControl loads and shows, but when I write anything it doesn't provide suggestions and I can't change the function it uses to fetch them as it comes from the settings

@getdave
Copy link
Contributor Author

getdave commented Sep 21, 2022

Hi @kaizen-lazevedo. The <LinkControl> is a component of the block editor and thus is designed to be used within that context. This is why it is not part of the @wordpress/components package. As a result there is not currently a way I'm aware of to pass a suggestions handler function into the component.

You could look at creating a registry for the UI you are creating which is what IsolatedBlockEditor does.

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) [Package] Core data /packages/core-data [Type] Experimental Experimental feature or API.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants