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

STCOR-635 wrap pluggable in suspense #1213

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from
Draft

STCOR-635 wrap pluggable in suspense #1213

wants to merge 3 commits into from

Conversation

zburke
Copy link
Member

@zburke zburke commented Jun 9, 2022

Wrap Pluggable's return value in Suspense in order to avoid whole-tree
re-renders, since the whole tree from the components up to the nearest
<Suspense> is removed and replaced with its fallback. For us, this is
particularly a problem when a plugin is part of a dropdown menu that
uses calculations to set its position. Because the entire tree will be
unmounted, the calculations all return zero, resulting in incorrect
placement with zero offset from the let margin (STRWEB-53).

h/t @BogdanDenis and @mkuklis for figuring this all out.

Refs STCOR-635

Wrap Pluggable's return value in Suspense in order to avoid whole-tree
re-renders, since the whole tree from the components up to the nearest
`<Suspense>` is removed and replaced with its fallback. For us, this is
particularly a problem when a plugin is part of a dropdown menu that
uses calculations to set its position. Because the entire tree will be
unmounted, the calculations all return zero, resulting in incorrect
placement with zero offset from the let margin (STRWEB-53).

h/t @BogdanDenis and @mkuklis for figuring this all out.

Refs STCOR-635
@zburke zburke requested review from mkuklis and BogdanDenis June 9, 2022 18:15
@github-actions
Copy link

github-actions bot commented Jun 9, 2022

Jest Unit Test Statistics

1 tests  ±0   1 ✔️ ±0   1s ⏱️ ±0s
1 suites ±0   0 💤 ±0 
1 files   ±0   0 ±0 

Results for commit e8ddb8a. ± Comparison against base commit 976a95c.

♻️ This comment has been updated with latest results.

@github-actions
Copy link

github-actions bot commented Jun 9, 2022

BigTest Unit Test Statistics

    1 files  ±0      1 suites  ±0   12s ⏱️ -1s
271 tests ±0  266 ✔️ ±0  5 💤 ±0  0 ±0 
274 runs  ±0  269 ✔️ ±0  5 💤 ±0  0 ±0 

Results for commit e8ddb8a. ± Comparison against base commit 976a95c.

This pull request removes 5 and adds 3 tests. Note that renamed tests count towards both.
      equal to check email label in english translation
      equal to check email precautions label in english translation
      equal to sent email precautions label in english translation
Chrome_102_0_5005_61_(Linux_x86_64).Forgot username form test ‑ Forgot username form test check email status page tests should have the header with an appropriate text content
Chrome_102_0_5005_61_(Linux_x86_64).Forgot username form test ‑ Forgot username form test check email status page tests should have the paragraph with an appropriate text content
Chrome_102_0_5005_61_(Linux_x86_64).Forgot username form test ‑ Forgot username form test check email status page tests should have the header with an appropriate text content
      equal to check email label in english translation
Chrome_102_0_5005_61_(Linux_x86_64).Forgot username form test ‑ Forgot username form test check email status page tests should have the paragraph with an appropriate text content
      equal to check email precautions label in english translation
Chrome_102_0_5005_61_(Linux_x86_64).Forgot username form test ‑ Forgot username form test check email status page tests should have the paragraph with an appropriate text content
      equal to sent email precautions label in english translation

♻️ This comment has been updated with latest results.

@zburke
Copy link
Member Author

zburke commented Jun 9, 2022

This is a nice idea, but it doesn't work. In a ui-inventory build with resolutions to this branch and to stripes-webpack with lazy turned back off for plugins, stripes isn't making its way through the hierarchy from StripesContext in stripesConnect:

Uncaught TypeError: Cannot read properties of undefined (reading 'connect')
    at new ConnectedComponent (stripesConnect.js:14:47)
    at constructClassInstance (react-dom.development.js:12716:1)
    ...

Interestingly, I also had to add dev-deps for stripes-form and stripes-final-form.

@mkuklis , @BogdanDenis , any ideas what could be going on?

@BogdanDenis
Copy link
Contributor

@zburke hmm, I get a completely different error

Cannot access '__WEBPACK_DEFAULT_EXPORT__' before initialization

I'll investigate this more today

src/Pluggable.js Outdated
import PropTypes from 'prop-types';
import { modules } from 'stripes-config';
import { withStripes } from './StripesContext';
import { ModuleHierarchyProvider } from './components';
import { LoadingView, ModuleHierarchyProvider } from './components';
Copy link
Contributor

Choose a reason for hiding this comment

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

@zburke I think <LoadingView> should come from @folio/stripes/components. This fixed my webpack error, but I didn't see what you reported in your comment

@sonarcloud
Copy link

sonarcloud bot commented Jun 10, 2022

SonarCloud Quality Gate failed.    Quality Gate failed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell B 1 Code Smell

0.0% 0.0% Coverage
0.0% 0.0% Duplication

@zburke zburke marked this pull request as draft June 12, 2022 11:24
Copy link
Contributor

@BogdanDenis BogdanDenis left a comment

Choose a reason for hiding this comment

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

Should use <Loading> instead - <LoadingView> will render a <Paneset> and this can potentially break pane resizing if there's a parent <Paneset>. Just spent a few hours debugging an issue that was caused by nested panesets, even though in theory they are valid.

I know it was I who suggested using <LoadingView> - so that's me fixing my mistake here

import PropTypes from 'prop-types';
import { modules } from 'stripes-config';
import { withStripes } from './StripesContext';
import { ModuleHierarchyProvider } from './components';
import { LoadingView } from '@folio/stripes-components';
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
import { LoadingView } from '@folio/stripes-components';
import { Loading } from '@folio/stripes-components';

@@ -37,7 +38,9 @@ const Pluggable = (props) => {
if (cachedPlugins.length) {
return cachedPlugins.map(({ plugin, Child }) => (
<ModuleHierarchyProvider module={plugin}>
<Child {...props} actAs="plugin" />
<Suspense fallback={<LoadingView />}>
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
<Suspense fallback={<LoadingView />}>
<Suspense fallback={<Loading />}>

@@ -47,7 +50,11 @@ const Pluggable = (props) => {
// eslint-disable-next-line no-console
console.error(`<Pluggable type="${props.type}"> has ${props.children.length} children, can only return one`);
}
return props.children;
return (
<Suspense fallback={<LoadingView />}>
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
<Suspense fallback={<LoadingView />}>
<Suspense fallback={<Loading />}>

@zburke
Copy link
Member Author

zburke commented Jun 24, 2022

@BogdanDenis, we turned off lazy-loading of modules for Morning Glory in stripes-webpack in folio-org/stripes-webpack#69, which should turn <Suspense> into a do-nothing component because there are no separate chunks to wait for. IOW, we do need to <Loading> instead of <LoadingView> for the nested-paneset reason you identify, but it doesn't matter now, right? I guess I'm just making sure your stripes-webpack is up to date :)

@BogdanDenis
Copy link
Contributor

BogdanDenis commented Jun 25, 2022

@BogdanDenis, we turned off lazy-loading of modules for Morning Glory in stripes-webpack in folio-org/stripes-webpack#69, which should turn <Suspense> into a do-nothing component because there are no separate chunks to wait for. IOW, we do need to <Loading> instead of <LoadingView> for the nested-paneset reason you identify, but it doesn't matter now, right? I guess I'm just making sure your stripes-webpack is up to date :)

Yes, since lazy loading is turned off for now we don't need it. Just wanted to comment this so we won't miss this when we decide to turn lazy loading back on and merge this PR

Also, I spoke with @JohnC-80 about nested panesets, and he said that they should work, and do work for plugins and settings, so I was wrong about nested panesets causing problems
But still it would make more sense IMO to use <Loading> here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants