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

Block displaying data with withAPIData only if window width below 782px #6379

Closed
tinboyko opened this issue Apr 24, 2018 · 1 comment · Fixed by #8584
Closed

Block displaying data with withAPIData only if window width below 782px #6379

tinboyko opened this issue Apr 24, 2018 · 1 comment · Fixed by #8584
Labels
Needs Testing Needs further testing to be confirmed.

Comments

@tinboyko
Copy link

Issue Overview

You can follow this example from Gutenberg handbook.
After post edit page reload, block not displaying fetched data from API if window width bigger than 782px and get stuck in loading state. In safari if i go back to pages and open this page again data is appeared. I noticed that if window width > 782px edit method of wp.blocks.registerBlockType is called twice.

Steps to Reproduce (for bugs)

  1. Create block with HOC withAPIData (example)
  2. Add this block in editor
  3. Save post
  4. Reload page

Chrome, Firefox, Safari

@keesiemeijer
Copy link

keesiemeijer commented Apr 25, 2018

I've got a similar issue with the Latest Posts block provided by Gutenberg (2.7 and 2.6).

Steps to Reproduce

  1. Add three latest posts blocks
  2. Change the "Order by" setting for the middle one
  3. Publish the post
  4. Refresh the page

Now the middle latest post block is stuck in loading state. Gutenberg 2.5 doesn't have this issue. I couldn't confirm if window width below 782px fixes this issue.

Tested in Firefox 59.02 with the default theme and no other plugins activated

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Testing Needs further testing to be confirmed.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants