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
Only show five inbox messages and add "Show more" button #35003
Conversation
Test Results SummaryCommit SHA: 1a9ba6e
Please address the following issues prior to merging this pull request: |
DEFAULT_INBOX_QUERY.per_page | ||
); | ||
const [ allNotesFetched, setAllNotesFetched ] = useState( false ); | ||
const [ allNotes, setAllNotes ] = useState( [] ); |
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.
This is used to store fetched notes, since we don't want them all to disappear (as happens with the returned notes
variable with useSelect
) while fetching more notes. This results in a much better UI experience.
@@ -238,15 +299,17 @@ const InboxPanel = ( { showHeader = true } ) => { | |||
|
|||
const noteId = note.id; | |||
try { | |||
removeNote( noteId ); | |||
await removeNote( noteId ); | |||
invalidateResolutionForStoreSelector( 'getNotes' ); |
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 seems we need to invalidate the data selector manually; I'm assuming this is due to the the fact that we're changing the inbox query with each request, but I haven't gotten too deep into this. Let me know if you see a more elegant way to manage 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.
Yeah that makes sense, I don't think there is a much better way around this at the moment, unless we add a new selector or change the selector to either ignore per_page
prop when returning the items, or use a separate selector that just returns all the notes
.
But this is fine!
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 think this will result in the simplest way to give the "rolling" notes appearance as we dismiss/etc notes. I'll keep it as is for the moment.
654dfe7
to
a0bcf7a
Compare
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.
Thanks for working on this @joelclimbsthings, this tested well. I did leave several comments within the code, not all of my suggestions are a must.
Given this would need to be in for the code freeze, the biggest item for me is having to use the notesHash
thing, if we could remove that then I would be happy.
I was wondering what exact scenarios you needed the hash for?
And curious if just removing the map
call within the useSelect
will remove the need of having to use the hash?
quantity_shown: allNotes.length, | ||
} ); | ||
setNoteDisplayQty( | ||
noteDisplayQty + ADD_NOTES_AMOUNT |
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.
Instead of relying on the noteDisplayQty
state to re-trigger the useSelect
hook, would it make more sense to remove the useSelect
hook and use resolveSelect
instead?
This allows you to run the getNotes
selector just like apiFetch
and it returns a promise, like so:
resolveSelect( NOTES_STORE_NAME ).getNotes( inboxQuery ).then( (notes) => setAllNotes(notes)
I am not opposed to the useSelect
but given the extra functionality I wonder if useSelect
would help simplify some of the logic, especially around when to set the all notes state.
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've greatly simplified the useSelect()
in the last commit, so I don't believe we'd see much benefit from this change. I haven't used resolveSelect()
, so I appreciate the insight!
@@ -238,15 +299,17 @@ const InboxPanel = ( { showHeader = true } ) => { | |||
|
|||
const noteId = note.id; | |||
try { | |||
removeNote( noteId ); | |||
await removeNote( noteId ); | |||
invalidateResolutionForStoreSelector( 'getNotes' ); |
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 that makes sense, I don't think there is a much better way around this at the moment, unless we add a new selector or change the selector to either ignore per_page
prop when returning the items, or use a separate selector that just returns all the notes
.
But this is fine!
a0bcf7a
to
47effe8
Compare
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.
One minor suggestion for the lint error, but otherwise this looks great and tested well!
@@ -142,59 +178,78 @@ const renderNotes = ( { | |||
); | |||
} ) } | |||
</TransitionGroup> | |||
{ allNotesFetched ? null : notesHaveResolved ? ( |
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.
Nested ternary expressions is not like by lint.
Maybe splitting this into two separate conditions would be the best?
Or could we show the InboxNotePlaceholder
when allNotesFetched
is false
?
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.
Hmm, not sure how I feel about that particular rule, but I've remedied this in 9516508.
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.
Thanks for working on this @joelclimbsthings, this looks good and it tested well, nice work!!
2d37a8b
to
1a9ba6e
Compare
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.
Thanks for fixing the test Joel, and I checked the E2E tests, they do not seem to be related. I saw the same one's fail in several other PRs.
I will merge this for you.
Hi @louwie17, thanks for merging this pull request. Please take a look at these follow-up tasks you may need to perform:
|
All Submissions:
Changes proposed in this Pull Request:
Reducing initial inbox messages to only display 5 messages, and adding the "show more" button to load another 10 messages at a time.
Closes #34927 .
How to test the changes in this Pull Request:
Other information:
pnpm --filter=<project> run changelog add
?FOR PR REVIEWER ONLY: