-
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
Add guards to decodeEntieties so it is not called with undefined. #6551
Add guards to decodeEntieties so it is not called with undefined. #6551
Conversation
I think you could try |
I'd rather not. Let's keep Alternative suggestion: Let's drop |
58c453d
to
a51751c
Compare
|
||
const debug = debugFactory( 'calypso:themes' ); | ||
let themeDetailsCache = new Map(); | ||
|
||
export function makeElement( ThemesComponent, Head, store, props ) { |
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.
themes/controller.jsx
is (was) using this function:
import { makeElement } from 'my-sites/theme/controller'; |
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.
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?
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 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' ); |
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'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 meta
s. :-)
Meta and title from |
Looking at |
type={ 'website' } | ||
canonicalUrl={ canonicalUrl } | ||
image={ this.props.screenshot } | ||
tier={ this.props.tier || 'all' }> |
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 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; |
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 FYI, there's a neat shorthand for a construct like this,
const { name: themeName } = this.props;
I added 7ba1648 so we can really get rid of the |
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, |
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.
Cool, I was seeing warnings for this.
Testing-wise this looks good to me. 👍 Merge when ready. |
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:
There should be no warnings regarding
decodeEntieties
being called withnull
,false
orundefined
.Test live: https://calypso.live/?branch=fix/call_to_decodeentieties_with_undefined