Fix: publish button delay #1263
Conversation
| setIsApproved(false) | ||
| onClose() | ||
| }} | ||
| /> | ||
| </> | ||
| ) | ||
| } | ||
|
|
||
| // NOTE: Utility component exists to soothe over state management |
There was a problem hiding this comment.
is this comment still relevant?
There was a problem hiding this comment.
Good catch, removed in 414b75d
| useEffect(() => { | ||
| if ( | ||
| reviewStatus === ReviewRequestStatus.CLOSED || | ||
| reviewStatus === ReviewRequestStatus.MERGED | ||
| ) { | ||
| setRedirectToPage(`/sites/${siteName}/dashboard`) | ||
| } | ||
| }, [reviewStatus, setRedirectToPage, siteName]) | ||
| if (reviewStatus && isApproved === null) { |
There was a problem hiding this comment.
hey I am confused with this code here :(
why are we setting it to approved when isApproved is null? if the idea to set them when we first run this code, this wouldn't play well well with a flow like approve -> disapprove -> approve? shouldnt this then just be if(reviewStatus) setIsApproved(reviewStatus === ReviewRequestStatus.APPROVED)?
There was a problem hiding this comment.
The idea for this code is to set isApproved only on initial load - isApproved is set to null originally, and if reviewStatus has finished loading, we set setIsApproved(reviewStatus === ReviewRequestStatus.APPROVED). From this point onwards, isApproved is only affected by the user's changes, which are immediate (as opposed to the previous behaviour of having to wait for the query from the backend)
Without the check for the first load, it gets stuck on the initial state of the page and has to rely on new information from the backend in order to change state!
|
This pull request has been stale for more than 30 days! Could someone please take a look at it @isomerpages/iso-engineers |
|
This pull request has been stale for more than 30 days! Could someone please take a look at it @isomerpages/iso-engineers |
This PR fixes an issue with the publish button not immediately reflecting the state of the reviewer's action. See video for current behaviour:
Screen.Recording.2023-05-04.at.4.38.25.PM.mov
The issue is that the publish now button is determined by our backend review request state instead of the user's direct action - the behaviour of the button state has been replicated to the publish now button as well.
As a safeguard, to prevent users from being able to publish even if the approval state has failed, an additional guard has been added to the backend in PR #752, to be reviewed in conjunction with this PR.