-
Notifications
You must be signed in to change notification settings - Fork 261
removes react-iframe-comm dependency #2861
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
Conversation
Codecov Report
@@ Coverage Diff @@
## master #2861 +/- ##
==========================================
+ Coverage 93.38% 93.43% +0.05%
==========================================
Files 151 152 +1
Lines 2281 2317 +36
==========================================
+ Hits 2130 2165 +35
- Misses 151 152 +1
Continue to review full report at Codecov.
|
bf37054 to
d8abe04
Compare
d8abe04 to
1e133b5
Compare
| @@ -0,0 +1,201 @@ | |||
| import React, { Component } from 'react'; | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is code copied from react-iframe-comm? We probably need to preserve the upstream license information in this file (and any others we're copying over.).
| /** | ||
| * | ||
| */ | ||
| export class IframeComm extends Component { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the reason for this living in src/lib because it is code copied from upstream? I would expect it to be in src/components
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lib is usually where compiled code goes so storing source in this directory is odd anyway, but in this case, since it is a "third party library component" (note also that it is a derivation, not a copy), it could/should reside in a directory that is distinct from your homegrown code (e.g. vendors) or even better, make a monorepo and build it as a separate package.
| @@ -0,0 +1 @@ | |||
| export * from './IFrameComm'; | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a new pattern that is needed?
| await page.waitFor(1000); | ||
| await expect(numWindows).toBe(2); | ||
| }); | ||
| }, 10000); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was this needed for the replacement of the iframe component? Were the tests failing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no, nothing to do with the component. these puppeteer tests consistently fail for me locally and also sometimes on CI. increasing the timeout solves it.
mejackreed
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few additional questions about this
|
FYI: I do not care whether this PR gets merged, but to resolve the issue, I suggest that you make whatever tangential changes you feel are appropriate. I do not spend anymore time on this. |
|
Ok thanks @christopher-johnson . We will close this for now and revisit if we need to. |
react-iframe-commbundlesreactandreact-dom. A PR towards resolving issue this upstream have had no response in several months, and it appears that this library is unmaintained. this solves the problem (and consequently reduces Mirador bundle size by ~7k). It removes the deprecated lifecyclecomponentWillReceivePropsfrom the component. Also, this resolves a console warning about the inline attribute on Typography. inWindowAuthenticationControl