-
Notifications
You must be signed in to change notification settings - Fork 0
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
EASI-4667 Side Panel Routing / State management #2901
EASI-4667 Side Panel Routing / State management #2901
Conversation
…s' into EASI-4667/panel-query-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.
@ClayBenson94 Yikes! Missed a line change in the reorg. Should be good now, sorry! |
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.
Appreciate that quick change -- looks like it's handling the proper views based on the query params now!
2 things I noticed when testing it out:
- I don't think we're refetching data on some of these forms, but that might be something that @aterstriep is handling with her form work (so we can ignore it here, if so!)
- I think this
Cancel
button on thereply
modal (src) should navigate back to theview
mode, rather than close the modal. Could you update that to usepushDiscussionQuery
? (Assuming that's the solution)- I think this will also handle it for the
start
view as well?
- I think this will also handle it for the
I'll have a look |
I did not work on the original queries, but I did notice that ids do exist on the entities, which afaik is at least part of a possible path to the refetching behavior. Cancel button in reply mode is updated. @ClayBenson94 |
If the refetching issue isn't simple we may want to split that out to a NOREF since the diff for this commit is big enough, imo. |
Yeah, I don't think the refetching is necessarily something we need to solve here -- the query param handling / navigation is a good spot to break this one off I think, so as long as all the buttons/links send to the right spots I'm good! |
I'm handling this in the PR I'll have up today to finish the discussion views work. I'll have a review up on this soon! |
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.
Nice job on this! I just found a couple of issues with the success/error alerts after submitting the form.
Can you add some unit tests to cover navigating between the different panel views?
@@ -77,15 +80,15 @@ const DiscussionForm = ({ | |||
message: t('general.alerts.startDiscussionSuccess'), | |||
type: 'success' | |||
}); | |||
|
|||
pushDiscussionQuery({ discussionMode: 'view' }); |
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 needs to go under the mutation block where I had left a TODO
comment before. On submit, the form should navigate back to the main discussion board view on both error and success (see Figma).
src/views/DiscussionBoard/index.tsx
Outdated
|
||
// Reset discussionAlert when side panel is opened or closed | ||
useEffect(() => { | ||
setDiscussionAlert(null); | ||
}, [setDiscussionAlert, isOpen]); | ||
}, [setDiscussionAlert, discussionMode]); |
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 see what you were trying to do here, but this discussionMode
dependency is preventing the discussionAlert
from showing after creating a new discussion.
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 pointing this out
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 actually not sure what should happen here with what you had originally + the new subview states.
The original comment says to reset on open or close, which was before the subview states. I used discussionMode because I figured the concept of open|close was similar enough to the mode subview switching, though the effect now is definitely wrong.
I test reverted to the isOpen
idea, but the alert just stays up if the user decides to keep interacting with more convos without closing the panel. Not saying a revert is what you're suggesting. Just not sure of where to go with what's set up.
Any ideas on how to approach? @aterstriep
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.
Ideally, the discussionAlert
needs to be reset in two instances:
discussionMode
changes fromreply
discussionMode
changes fromview
If I remember right, Mint uses setTimeout
to close their alerts after a certain time period. So alternatively we could do it that way as well as reset when the modal is opened or closed.
Happy to pair on this later today if that would be helpful!
src/hooks/useDiscussionParams.ts
Outdated
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.
Good idea to separate this code into a custom hook!
@aterstriep Weren't you planning to take on the cypress tests? I think that would cover testing. |
@aterstriep There was also the refetching issue that was pointed out up the thread. Seemed like it would have been part of your current follow-up work but not sure. |
@adamodd I left a comment about this above but forgot to tag you. Yes, this will be handled in the follow-up work. |
@aterstriep Okay, let me know what you have in mind for unit tests in this PR. I'm not clear on what it should be because the refetching issue is being handled in yours, and I thought I at least heard in passing that you would take on the cypress tests next. We can unit test the state handling, but I think there's less to code with the cypress testing methods and might prefer that. |
Regarding Testing -- if the JS tests are simple to add in, I think it could be nice to have even just some snapshot tests that ensure things render as expected given certain props/state, even if we don't go all out with handling navigating between different views in the tests (and just save that for Cypress) Maybe some tests that just ensure the right things are rendered based on |
@adamodd I was thinking just some basic unit tests to make sure the right content is shown at each view, but I'm good with handling this in Cypress tests instead. The Cypress tests have been ticketed but we haven't discussed who would be taking it on. @ClayBenson94 we can't use snapshots for the discussions work. Some of the dates are displayed as "X days ago", so the snapshots would change every day. I figured this out the hard way 😅 |
@aterstriep @ClayBenson94 The alert issue is fixed. That looked like the last outstanding item. Tests will continue in the separate ticket. There were also some unit tests for renders already done. |
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.
Changes look good!
EASI-4667
Description
New hook
useDiscussionParams
to wrap url query handling.Use new url search query params
discussionMode
anddiscussionId
with modes for subview states. Example query strings?discussionMode=view
?discussionMode=start
?discussionMode=reply&discussionId=63deffff-31be-49ca-9733-8247d0446cda
For the base path
/it-governance/61efa6eb-1976-4431-a158-d89cc00ce31d/grb-review
Names and param format is not fixed and open for discussion.
Using query params is probably the way to go for the modal states of a higher-level view, instead of something such as appending further route paths (under grb.)
How to test this change
PR Author Checklist
PR Reviewer Guidelines