-
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
Media: add media section #11822
Media: add media section #11822
Conversation
66fce78
to
2474f28
Compare
5d54642
to
98cdd8e
Compare
9ae39f5
to
2e280ee
Compare
cc @alisterscott @hoverduck would it be possible to run e2e's against this branch? Let us know if we need to update any test suites. |
c735f39
to
e6e6b0b
Compare
@gwwar The e2e tests look good except (unsurprisingly) the media upload test needs some updates. Since you're the original author can you take a look? If not I can get to it tomorrow |
const eventProperties = { cta_name: 'plan-media-storage' }; | ||
return ( | ||
<PlanStorage siteId={ this.props.site.ID }> | ||
<TrackComponentView eventName={ eventName } eventProperties={ eventProperties } /> |
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.
fun fact! when I'm just passing named properties like this I find the spread syntax helpful…
<TrackComponentView { ...{
eventName,
eventProperties
} } />
Thanks @hoverduck I'll try to take a look at that today |
|
||
if ( isError || ! this.props.site ) { | ||
event.preventDefault(); |
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 quick drive-by comment - it seems we need to call event.preventDefault()
in both cases, so it should probably be called once (before this if branch and removed from line 45) - otherwise someone might think that one of these calls should not be there :)
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'm sorry Igor, I don't understand completely what do you mean. Could you point straight in the file of this PR? I'm sorry. It seemed to be a connection issue since I couldn't see this comment 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.
Now I got it. You're right. Thanks.
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.
Ah, sorry. So, no matter which flow we take in this function we end up calling event.preventDefault
. Either here: https://github.com/Automattic/wp-calypso/pull/11822/files#diff-246b58e6f07d7dce525ca439d82eccf9R41 or here: https://github.com/Automattic/wp-calypso/pull/11822/files#diff-246b58e6f07d7dce525ca439d82eccf9R45.
So I thought that this call should be "deduplicated" and moved to a single call, somewhere above https://github.com/Automattic/wp-calypso/pull/11822/files#diff-246b58e6f07d7dce525ca439d82eccf9R40. Less chances of one of these calls getting deleted and it shows the intent (always prevent default behaviour of the event) better.
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.
Actually, this line seems to be unneeded. Good one 👍
client/my-sites/media/main.jsx
Outdated
|
||
accept( confirmMessage, accepted => { | ||
if ( ! accepted ) { | ||
return null; |
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.
Seems like just return;
should suffice :)
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, agree. But I've gotten feedback from other PR that we should be explicit in this sense. Although return
returns a null
if nothing is defined, it's more understandable when the null
value is defined explicitly.
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.
Ah, got it - I was thrown off by no explicit return in the success scenario, but if that's intended then cool 👍
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 ... we aren't being consistent with this. :-|
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.
Although return returns a null if nothing is defined, it's more understandable when the null value is defined explicitly.
interesting…what reason was given to be explicit in the return value there?
also this is wrong. return
returns undefined
if no value is given.
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.
also this is wrong. return returns undefined if no value is given.
You're right. Another reason to return null
;-)
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.
You're right. Another reason to return null ;-)
the way I typically do it is that if my only reason to use return
is to early-abort from a function then I'll just return
because that's how it would have happened if the function had returned normally given no explicit value.
if, on the other hand, the function is designed to return a value and something else is counting on it I'll want to explicitly return something. bonus points if it's the same data type as would otherwise return.
for example, an empty string could be more appropriate for a string function than null
, a 0
might be more appropriate for a number function, an empty list for a list function, etc…
but if I'm calling a function for its side-effects only and don't expect a value, I think getting something back could also be confusing
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.
But I've gotten feedback from other PR that we should be explicit in this sense. Although return returns a null if nothing is defined, it's more understandable when the null value is defined explicitly.
Do you have the link @retrofox? We might have gotten confused that this was a render helper. A return null
for rending is an explicit indication for React that we want to render nothing.
I missed this on the original PR, but it doesn't look like anything uses this return value, in which case we should just return;
I agree with @dmsnell on consistency. A function should either always return some value if we're using it, or nothing if we don't.
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, sorry. Last night I forgot to leave my answer here.
I was confusing with the render method of React component. Let me update the code. I'm sorry again and thanks!
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.
rebased and updated
@gwwar: if you don't find time please LMK and I can do this for you |
Thanks @folletto for testing!
@retrofox let's update styling for this
I think we can follow up pretty quickly and discuss points 2 and 3 after the feature branch lands. |
f1f89b0
to
eefefd6
Compare
It's a nitpick, but i'd make the clickable item |
f5061c2
to
fbb8ffc
Compare
fbb8ffc
to
3d16a80
Compare
yes, already done. I've removed the |
This PR makes a number of improvements to the media section and updates the media modal to include an action bar at the top. The media section is controlled by the
manage/media
feature flag. This is currently enabled in dev, wpcalypso, horizon and test. The media section can be shown by clicking on theMedia
option into the sidebar.Related Design Discussion: #10805
The whole picture
Primary Changes
Beyond add the media library this PR implements many changes. Following, the most important ones:
Media -> Add item
It allows adding a new item quickly.
Media -> Actions bar
Media -> Plan storage nudge
A plan storage nudge is shown in the filter bar is the site doesn't have a business plan.
Media -> Item detail dialog
DONE
andDELETE
buttonsPost editor -> add media -> Item detail dialog
Testing Instructions:
Media Modal
Media Section
Site Icon
Known Visual Issues
There are a few known visual issues in the media section that should be addressed after this feature branch lands. It should be safe to land with these quirks since the media section is not enabled in prod yet. We're hoping to land the feature branch quickly to avoid drift and a larger diff.
Pull Requests
This process was done working in different patches:
Done
andDelete
buttons Media: addDone
andDelete
buttons #11910h/t to @iamtakashi @artpi @retrofox @gwwar