-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Site Importer: Add Site Importer Beta to Calypso #23930
Conversation
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.
How much testing have we done against the existing import methods with this diff?
}; | ||
|
||
componentWillUnmount() { | ||
window.clearInterval( this.randomizeTimer ); |
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 interval doesn't seem used... Can it be pulled out?
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.
It's a leftover from previous importer code and it's unused. Removed.
|
||
render() { | ||
importerData.description = this.props.translate( | ||
'Import posts, pages, and media ' + 'from your existing site!' |
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.
why is this concatenated? can it be joined w/o exceeding the line limit?
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.
Something got lost somewhere in updating the strings :) Thanks for noticing! Updated.
* Module variables | ||
*/ | ||
const importerData = { | ||
title: 'Site Importer', |
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.
Can we add a (Beta)
label to this in the meantime so folks in dev don't expect it to work 100% in the dev env?
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.
Yes, great suggestion. Added the label.
This method doesn't touch on current imports code. To be on the safe side I tested it with WordPress imports and it seems to be working properly. There's an ongoing issue with Medium imports at the moment - #17631 , which is not related to the current PR. |
siteURLInput: '', | ||
}; | ||
|
||
// TODO This can be improved if we move to Redux. |
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 fn looks awful with those defers but agreed that we can handle it better once switching to redux.
The only question that's left for me is whether to use |
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.
Re: the translate
usage, I'd err on the side of not translating until finalised. For strings that are certainly translated already (translate( 'no' )
for instance) that's not a problem as we're not making work for translators that may/may not be staying.
/** | ||
* Module variables | ||
*/ | ||
const importerData = { |
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 there specific benefit to creating the importerData
obj here and building on it in render
(other than to use translate
at the right time)? It seems to add some indirection for little gain.
I think we could use the property initializer shorthand to set these strings on the component like so:
static propTypes = { ... }
someCopy = {
copy1: this.props.translate( 'Some copy' ),
copy2: this.props.translate( 'Some more copy' ),
};
render() { ... }
The benefit of which being that translate would only be called once per component being created.
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.
Yes, this definitely sounds better. Improved the code.
@@ -153,8 +155,13 @@ class SiteSettingsImport extends Component { | |||
<MediumImporter { ...{ key, site, importerStatus } } /> | |||
) ) } | |||
|
|||
{ isEnabled( 'manage/import/site-importer' ) && | |||
siteImporterImports.map( ( importerStatus, key ) => ( |
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.
Here, and inn other mappings I see the index used as a key - Is this not something we should be concerned about? I know that generally folk see it as an anti-pattern (# # and the official react docs mention that index should only be used as a last resort. I'm not so sure if there is anything better in the data though so please ignore if the index is the only differentiation we can make here :)
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.
Yes, this is part of the legacy code :) We'll iterate and refactor the section to follow more recent practices and make it work/look better.
const { title, icon, description, uploadDescription } = this.props.importerData; | ||
const site = this.props.site; | ||
const state = this.props.importerStatus, | ||
isEnabled = appStates.DISABLED !== state.importerState, |
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.
nit: should we use const
for each line here?
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.
Updated.
* Module variables | ||
*/ | ||
const compactStates = [ appStates.DISABLED, appStates.INACTIVE ], | ||
importingStates = [ |
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.
nit: should we use const for each line here?
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.
Updated.
} | ||
|
||
const mapDispatchToProps = dispatch => ( { | ||
mapAuthorFor: importerId => ( source, target ) => |
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.
I may be wrong, but would it not be worth creating a new action for this? It seems like a lot of logic for the mapDispatchToProps
cb
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.
It was the easiest way to achieve the functionality. I agree it would make more sense to extract is a separate action, but with the underlying Flux code, I don't think it makes sense to add more things there instead of focusing on migrating to Redux and improving the code here after that.
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.
That makes sense :)
render() { | ||
return ( | ||
<div className="site-importer__site-importer-pane"> | ||
{ this.state.importStage === 'idle' && ( |
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.
I think a slight improvement here would be to make these state labels constants, so we can compare like:
this.state.importStage === IDLE_STATE &&
etc.
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.
It would be awesome to extract that while refactoring the import section, so we can unify it between all the importers.
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.
Let's get this in Dev!
This PR adds a beta version of the Site Importer interface. Currently enabled only in development mode, while we figure out bugs and issues in the UX.