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

Site Importer: Add Site Importer Beta to Calypso #23930

Merged
merged 4 commits into from
Apr 13, 2018
Merged

Conversation

bisko
Copy link
Contributor

@bisko bisko commented Apr 5, 2018

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.

@bisko bisko added [Type] Enhancement [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. Import labels Apr 5, 2018
@bisko bisko self-assigned this Apr 5, 2018
@bisko bisko requested review from marekhrabe and jblz April 5, 2018 14:03
@matticbot
Copy link
Contributor

Copy link
Member

@jblz jblz left a 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 );
Copy link
Member

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?

Copy link
Contributor Author

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!'
Copy link
Member

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?

Copy link
Contributor Author

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',
Copy link
Member

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?

Copy link
Contributor Author

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.

@bisko
Copy link
Contributor Author

bisko commented Apr 5, 2018

How much testing have we done against the existing import methods with this diff?

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.
Copy link
Contributor

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.

@marekhrabe
Copy link
Contributor

The only question that's left for me is whether to use translate() or not. This PR mixes both approaches and I think we should settle on one before merging. Other than that decision, this PR looks good to me to be 🚢soon!

Copy link
Contributor

@spen spen left a 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 = {
Copy link
Contributor

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.

Copy link
Contributor Author

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 ) => (
Copy link
Contributor

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 :)

Copy link
Contributor Author

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,
Copy link
Contributor

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?

Copy link
Contributor Author

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 = [
Copy link
Contributor

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?

Copy link
Contributor Author

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 ) =>
Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor

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' && (
Copy link
Contributor

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.

Copy link
Contributor Author

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.

@bisko bisko mentioned this pull request Apr 13, 2018
Copy link
Member

@jblz jblz left a 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!

@bisko bisko merged commit 2e3a7be into master Apr 13, 2018
@bisko bisko deleted the add/site-importer-beta branch April 13, 2018 18:41
@matticbot matticbot removed the [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. label Apr 13, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants