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

Add guards to decodeEntieties so it is not called with undefined. #6551

Merged
merged 16 commits into from
Aug 1, 2016

Conversation

budzanowski
Copy link
Contributor

@budzanowski budzanowski commented Jul 6, 2016

In initial loading phase code was calling decodeEntieties before data was available.
Now we check if the data is ready before the call.

To check:

  1. open /desing
  2. open /theme (info)
  3. observe console

There should be no warnings regarding decodeEntieties being called with null, false or undefined.

Test live: https://calypso.live/?branch=fix/call_to_decodeentieties_with_undefined

@budzanowski budzanowski added [Feature Group] Appearance & Themes Features related to the appearance of sites. [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. labels Jul 6, 2016
@budzanowski budzanowski added this to the Themes: Maintenance milestone Jul 6, 2016
@budzanowski budzanowski self-assigned this Jul 6, 2016
@ockham
Copy link
Contributor

ockham commented Jul 7, 2016

I think you could try decodeEntities( param || '' ) instead. This way, the conditional is contained inside the argument, and using the fallback-or reads a bit better than the ternary IMO.

@seear
Copy link
Contributor

seear commented Jul 12, 2016

This fix gets rid of the warning, but the problem remains that we are rendering the page without the proper title:
screen shot 2016-07-12 at 13 09 34

Could we connect my-sites/themes/head to the redux store and use the theme title and description when they become available instead of passing them in as props?

@ockham
Copy link
Contributor

ockham commented Jul 12, 2016

Could we connect my-sites/themes/head to the redux store

I'd rather not. Let's keep Head as dumb as possible for now and wait for #3795 to replace it properly.

Alternative suggestion: Let's drop makeElement, and move the <Head> wrapping to main.jsx -- as part of the component definition. That will connect() it. :-)

@budzanowski budzanowski force-pushed the fix/call_to_decodeentieties_with_undefined branch from 58c453d to a51751c Compare July 26, 2016 08:43

const debug = debugFactory( 'calypso:themes' );
let themeDetailsCache = new Map();

export function makeElement( ThemesComponent, Head, store, props ) {
Copy link
Contributor

Choose a reason for hiding this comment

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

themes/controller.jsx is (was) using this function:

import { makeElement } from 'my-sites/theme/controller';

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ahh yes :( . Function added to themes/controller.jsx - it is just a helper function for that file now. Is there a reason that it should not be used this way(or in any way)? - @ockham wants to get rid of this function but i think it was horrible only in context of Theme Sheet, or there is more complicated reason?

Copy link
Contributor

Choose a reason for hiding this comment

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

I still want to get rid of it for themes lists too, but that can wait for another PR.

It's just a layer of indirection we don't really need any more. Ideally, we want some sort of generic adapter that connects a component to a routing middleware, and I had originally envisaged makeElement to be that (when it contained even more logic). However, I don't think so anymore; e.g. its signature isn't really good -- for example, it shouldn't have to accept Head as an arg.

But yeah, moving it to where it is actually used is fine for now.

@@ -345,33 +346,53 @@ const ThemeSheet = React.createClass( {
const analyticsPath = `/theme/:slug${ section ? '/' + section : '' }${ siteID ? '/:site_id' : '' }`;
const analyticsPageTitle = `Themes > Details Sheet${ section ? ' > ' + titlecase( section ) : '' }${ siteID ? ' > Site' : '' }`;

const Head = this.props.isLoggedIn
? require( 'layout/head' )
: require( 'my-sites/themes/head' );
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd really love if we could get rid of the conditional import while we're here; I'm quite sure layout/head is all we ever need here. You can read its source (and compare to what fields we override here in main.jsx) to validate that assumption -- or maybe just try without and compare resulting title and metas. :-)

@budzanowski
Copy link
Contributor Author

Meta and title from Head from layout looks OK.
TODO added.

@ockham
Copy link
Contributor

ockham commented Jul 29, 2016

Looking at my-sites/themes/head, I think there is one default defined there that we actually need here, too -- site_name. But I think that default value (WordPress.com) isn't themes specific anyway, so it should probably go to layout/head. (See the first couple of commits of #6814.)

type={ 'website' }
canonicalUrl={ canonicalUrl }
image={ this.props.screenshot }
tier={ this.props.tier || 'all' }>
Copy link
Contributor

Choose a reason for hiding this comment

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

No need for this prop.

@@ -345,33 +347,48 @@ const ThemeSheet = React.createClass( {
const analyticsPath = `/theme/:slug${ section ? '/' + section : '' }${ siteID ? '/:site_id' : '' }`;
const analyticsPageTitle = `Themes > Details Sheet${ section ? ' > ' + titlecase( section ) : '' }${ siteID ? ' > Site' : '' }`;

const themeName = this.props.name;
Copy link
Contributor

Choose a reason for hiding this comment

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

Just FYI, there's a neat shorthand for a construct like this,

const { name: themeName } = this.props;

@ockham
Copy link
Contributor

ockham commented Aug 1, 2016

I added 7ba1648 so we can really get rid of the decodeEntities( /* something*/ || '' ) fallbacks. Theme details will now be fetched as part of the fetchThemeDetailsData middleware on the client-side, too (unless they're already there, e.g. from initialState provided by the server). Would appreciate if you both could have a look @bb and @seear.

@ockham
Copy link
Contributor

ockham commented Aug 1, 2016

If you cherry-pick 31adaf0 and 2538eaa from #6814, I can close that one :-)

ockham added 3 commits August 1, 2016 16:12
This reverts commit 7ba1648.

We don't really want to wait for data to be fetched before rendering.
While it technically is required, this doesn't work with `ThemeMultiSiteSelector` (which clones its child element).
@@ -73,7 +75,7 @@ const ThemeSheet = React.createClass( {
label: React.PropTypes.string.isRequired,
action: React.PropTypes.func,
getUrl: React.PropTypes.func,
} ).isRequired,
Copy link
Contributor

Choose a reason for hiding this comment

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

Cool, I was seeing warnings for this.

@seear seear added [Status] Ready to Merge and removed [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. labels Aug 1, 2016
@seear
Copy link
Contributor

seear commented Aug 1, 2016

Testing-wise this looks good to me. 👍

Merge when ready.

@budzanowski budzanowski merged commit 9ea12f5 into master Aug 1, 2016
@budzanowski budzanowski deleted the fix/call_to_decodeentieties_with_undefined branch August 2, 2016 01:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature Group] Appearance & Themes Features related to the appearance of sites.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants