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

addEventListener 'load' not working on FSE editor. #39114

Closed
grogou opened this issue Feb 28, 2022 · 9 comments
Closed

addEventListener 'load' not working on FSE editor. #39114

grogou opened this issue Feb 28, 2022 · 9 comments
Labels
[Feature] Site Editor Related to the overarching Site Editor (formerly "full site editing")

Comments

@grogou
Copy link

grogou commented Feb 28, 2022

Description

ref.current.addEventListener('load') not working on FSE editor, but it is working on standard editor.
Nothing on console, just listener don't fire.

Step-by-step reproduction instructions

  1. Create custom block and add some load listener on some ref

Screenshots, screen recording, code snippet

No response

Environment info

Wordpress 5.9.1
Gutenberg 12.6.1

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

@t-hamano
Copy link
Contributor

t-hamano commented Mar 2, 2022

I think a window object would be appropriate for attaching the load event.

And I think useRefEffect would be a good choice based on Make WordPress Core article.

Like this:

import { useRefEffect } from '@wordpress/compose';
import { useBlockProps } from '@wordpress/block-editor';

export default function Edit() {
	const ref = useRefEffect( ( element ) => {
		function someFunc() {
			// do something...
		}

		const { ownerDocument } = element;

		// Relative window object
		const { defaultView } = ownerDocument;

		defaultView.addEventListener( 'load', someFunc );

		return () => {
			// remove event listener.
			defaultView.removeEventListener( 'load', someFunc );
		};
	}, [] );

	const blockProps = useBlockProps( { ref } );

	return (
		<p { ...blockProps }>test</p>
	);
}

@grogou
Copy link
Author

grogou commented Mar 2, 2022

@t-hamano thank you for this, but is there some difference between standard editor and FSE editor? and about window listeners, my case is not use window.addEventListener it fire event on ref.

@t-hamano
Copy link
Contributor

t-hamano commented Mar 2, 2022

@grogou
Unlike a regular editor, the site editor is an iframe editor instance, so when binding events to the windows object, a relative window (defaultView) starting from ref must be used.
(I don't know why the load event is not fired in the site editor when the load event of ref.current is applied...)

@grogou
Copy link
Author

grogou commented Mar 3, 2022

@t-hamano thank you it is lot of help.

@grogou
Copy link
Author

grogou commented Mar 3, 2022

useRefEffect not working too. So the problem is site editor or idk, is someone know how can this issue will be fixed?

@t-hamano
Copy link
Contributor

t-hamano commented Mar 3, 2022

Perhaps the event is not attached because the document is already loaded in the site editor (iframe editor instance).

I think it would be better to do the processing directly within useEffect without attaching the event.

import { __ } from '@wordpress/i18n';
import { useEffect, useRef } from '@wordpress/element';
import { useBlockProps } from '@wordpress/block-editor';

export default function Edit() {
	const ref = useRef( null );

	useEffect( () => {
		const { ownerDocument } = ref.current;

		// should show "complete", this means that the document has been loaded.
		console.log( ownerDocument.readyState );

		// Do something directly without using event listener.
	}, [] )

	const blockProps = useBlockProps({ ref });

	return (
		<p { ...blockProps }>
			{ __( 'Test Block – hello from the editor!', 'test-block' ) }
		</p>
	);
}

@annezazu
Copy link
Contributor

Curious if @ryanwelcher has any insights here!

@annezazu annezazu added Needs Technical Feedback Needs testing from a developer perspective. [Feature] Site Editor Related to the overarching Site Editor (formerly "full site editing") labels Mar 30, 2022
@grogou
Copy link
Author

grogou commented Apr 1, 2022

@annezazu anyway this is not working in my side, so if you can suggest anything for this I will by glad for that.
Or if there complex way to understand this cases with "iframes". Where I can read about that something?

Thank you!

@grogou grogou closed this as completed May 10, 2022
@annezazu
Copy link
Contributor

For iframing, I'd recommend checking out this issue @grogou: #33346 Apologies for missing your ping earlier!

@t-hamano t-hamano removed the Needs Technical Feedback Needs testing from a developer perspective. label Aug 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Site Editor Related to the overarching Site Editor (formerly "full site editing")
Projects
None yet
Development

No branches or pull requests

3 participants