fix(client): no submit on server fail #42973
Conversation
|
|
github-actions
bot
added
the
platform: learn
| concat(of(updateSolutionFormValues({}))) | ||
| switchMap(project => { | ||
| const { type, payload } = project; | ||
| if (type === challengeActionTypes.updateFailed) { | ||
| return of(updateFailed(payload)); | ||
| } | ||
| return of(updateSolutionFormValues({})); | ||
| }) |
There was a problem hiding this comment.
I'm not sure about this. The issue was, I thought, that action with type == submitChallenge was being dispatched twice, one of which would trigger the error flash and one of which would close the modal and navigate.
This solves the problem, but only by conditionally dropping the actions that're piped in. Instead, should we simply only dispatch a single action?
There was a problem hiding this comment.
I am not sure. I thought it needed to dispatch one of those actions, in order for the chain to continue.
There was a problem hiding this comment.
I'm just not convinced two submitChallenge actions should be dispatched.
There was a problem hiding this comment.
@ahmadabdolsaheb am I missing something here? What we're trying to achieve is:
User clicks submit -> client talks to server -> server responds with error -> user is warned
or
User clicks submit -> client talks to server -> server responds with success -> modal is closed -> navigate to next page
and what I'm worried about is that the action that's dispatched to trigger this seems to get dispatched twice.
There was a problem hiding this comment.
After chatting with @ahmadabdolsaheb we realised that ideally it should both ignore duplicate submitChallenges and just dispatch a single action. Reason being rapid submission is almost certainly a bug, so we should code defensively. And, well, if a single click creates two submissions that's definitely a bug.
|
Sorry for thinking about this so late, but do we definitely want to wait for a server response before the user can continue? The reason I ask is that this is not how we do things for the rest of the challenges - we just let them continue and save the submission in local storage. Do we maybe want to keep the existing behaviour, but make sure that the warning persists? |
The way I see it, whilst we might not want to unnecessarily delay a Camper from completing challenges quickly sans saving, project submissions are different, and not meant to be "rushed" through. That is, I suspect most Campers want utter-and-complete confirmation their project submission has gone through, and, if not, then they want to try again, or, realise they have submitted something the server is never going to be happy with. |
|
That makes sense. As long as we only change the flow for project submission, that sounds like a plan. |
|
Cleaning things up. Added this to your Trello, so that you can come back and resurrect this when you are ready. |
Checklist:
Update index.md)mainbranch of freeCodeCamp.Closes #37615
22/07/2021 This includes the change in
solution-formto fail a submission - for testing.This does not make use of the
updateFetchStatestate, as I am leaving this open for some discussion as how best to use it. ?This was largely possible thanks to the help of these developer: Oliver