-
-
Notifications
You must be signed in to change notification settings - Fork 311
feat: New MusicBrainz Homepage #3669
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
base: master
Are you sure you want to change the base?
Conversation
|
Thanks for opening your first pull request for MusicBrainz Server, and welcome to our community! 🎉 |
reosarevok
left a comment
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 haven't gotten to the scripts folder yet, so more coming tomorrow probably for that, but putting up the comments I have for now since there's... a fair bunch. A lot are just trivial indent fixes though :)
| WHERE event_art_type.type_id = ? | ||
| AND event_art.ordering = 1 | ||
| AND edit.type = ? | ||
| AND event_art.date_uploaded < NOW() - INTERVAL '10 minutes' |
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 limit (this much, at least) the art upload date if what we care is to see the most current events? Wouldn't it be better to just show the ones for the recent past and maybe the upcoming week that have artwork if any? Same for fresh releases.
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 looks like this line is just ensuring the uploads are at least 10 minutes old, which was copied from 6add14f.
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.
Oh. Duh. I should read properly.
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.
A small issue I do see with this query is that events displayed here seem guaranteed to be the same for quite a while if someone adds a tour a few months in the future. So I still think (even if it's unrelated to this specific line) having some sort of "max X days in the future" makes sense to show stuff here too. What do you feel?
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 to me. I'd probably keep it short, like max 3 days into the future.
reosarevok
left a comment
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 haven't gotten to the scripts folder yet, so more coming tomorrow probably for that, but putting up the comments I have for now since there's... a fair bunch. A lot are just trivial indent fixes though :)
|
The browser console is being spammed with some swiper-related warning. Can you look into that too? :)
|
| const [isHydrated, setIsHydrated] = React.useState(false); | ||
|
|
||
| React.useEffect(() => { | ||
| setIsHydrated(true); |
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.
If we plan to show the "Editor tools" dropdown on every page in the future, it seems like the toggled state would make more sense as a cookie setting. Otherwise someone who wants it collapsed has to manually collapse it on every page load. You can also read the cookie on the server and client, so don't need the isHydrated hack.
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.
If we have a cookie, do we even need the isMobile / useMediaQuery bits? I'm not quite sure why we would hide them by default on mobile, I think it seems useful to show them to users once at least even if they are mobile users. I guess the main point is they would get in the way if open all the time, which a cookie would hopefully solve.
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's what it looks like on my iPhone with the editor tools menu closed and then open (ignore the battery percentage 💀).
So it looks like it would make sense to keep it initially collapsed on mobile since it takes up the entire screen. At the same time, the button is blocking part of the "Welcome back" text. :)
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.
Fair enough I guess - arguably we could have it initially collapsed everywhere though and just trust the cookie :)
| "punycode": "2.3.1", | ||
| "react": "18.3.1", | ||
| "react-dom": "18.3.1", | ||
| "react-lazy-load-image-component": "^1.6.3", |
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 prefer to just use https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/img#lazy rather than bringing in a new dependency. We use it in root/static/scripts/common/components/Artwork2.js already and perhaps this component can be used by the homepage too.
reosarevok
left a comment
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 just noticed this change is entirely dropping the admin menu. Please make sure it's available somewhere, either on the top as now or (since I guess it doesn't fit well there) at the very least on the "Editor tools" section.
Most if not all the /homepage files seem like they should be named in UpperCamelCase, since they are components (MobileSearchPopup and whatnot).
| role="button" | ||
| > | ||
| <FontAwesomeIcon icon={faPlusCircle} /> | ||
| {l('Add new...')} |
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.
Another dropdown menu like this should probably be added for the Admin menu. Right now, you seem to be dropping it entirely (no longer on the header, not in here either), which is obviously not ideal :)
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.
reosarevok
left a comment
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.
Last few comments (I did not check the less files nor the tests at the moment).
Sorry about some duplicate comments being sent, I thought I lost them at first because of github hiding comments for huge PRs.
| <h2>{l('Welcome back')}</h2> | ||
| <a className="username-link" href={`/user/${user?.name}`}> | ||
| <h2 className="username"> | ||
| {user?.name} | ||
| </h2> |
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.
These two should probably be combined using exp.l() (the order won't be the same for all languages, some will need the name to go first or in between). I understand this might not be entirely trivial since you probably want them in two lines, but still. @mwiencek might have some ideas?
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.
Yeah, something like Welcome back {username} would make more sense to me. You can pass the whole <a> section in for username and use CSS to add a line break.
I'm not sure it makes sense to use h2 either, because it's not a semantic heading (doesn't describe the section at all).
ddbbfe4 to
375f7ce
Compare
ad843a4 to
4f8c861
Compare
String locations are needed when building translations for the client-side JS (which uses msggrep). This should prevent, e.g., hydration errors in cases where a string has been moved.
…omponent type definitions
`l` was being incorrectly used on dynamic strings that weren't previously marked with `N_l` within the same file.
* `lp` is unused. * `l` is auto-imported by the ProvidePlugin.
`l` was being incorrectly used on dynamic strings that weren't previously marked with `N_l` within the same file.
Co-authored-by: Nicolás Tamargo <reosarevok@metabrainz.org>
4f8c861 to
a62f676
Compare
…itor tools with cookie-based state management
…rver into ansh/new-homepage

Problem
🔰 Reference related tickets with MBS-XXX at least.
Solution
🔰 If you have a lot to say, be more detailed in this section.
Testing
🔰 If you tested anything on specific pages, mention them here, such as:
Tested something on
/release/mbidusing a sample/full databaseDocumenting
🔰 If you updated documentation pages, mention them here, such as:
Updated WikiDocs page
Draft progress
Further action