Get Processing Status from Redis into the frontend

[FinnIckler]

I wouldn't mind also getting the registration into the page and conditionally checking for if processing only if no registration exists, but I would need to touch the v1
@registration = @competition.registrations.find_or_initialize_by(user_id: current_user.id, competition_id: @competition.id)
line which sounds dangerous for the little time we have to get this out

[FinnIckler]

@thewca-bot deploy staging

[FinnIckler]

@thewca-bot deploy staging

[FinnIckler]

@kr-matthews any idea why this causes an infinite loop?
-> Setting isProcessing to true from Rails
-> starting Processing polling which sets the state to true
-> that finishes and sets the state to false
-> rerendering sets the state to true again (from the boolean coming from rails presumably)
-> loop

I thought doing it like this

const [processing, setProcessing] = useState(false);

  useEffect(() => {
    setProcessing(isProcessing);
  }, [isProcessing]);

will make sure the value will not override it again.

[gregorbg]

What goes against just using the isProcessing that is passed in from the backend as initial value for this state?

[FinnIckler]

When a user refreshes while processing, then processing finishes, react rerenders and it will set it to true again, which will cause it to be stuck in a process -> finish -> process loop

[FinnIckler]

I tried to fix that with the useEffect, but it still occurs

[gregorbg]

But the loop is being caused by the useEffect. My point was to remove the useEffect and instead use the initialization value here.

[FinnIckler]

it is not. I had it exactly like you proposed previously and it caused the same loop

[FinnIckler]

fc0048e
see first commit

[gregorbg]

I don't see an "easy" solution here. The problem is that the "backend" version of isProcessing is taken as a ground truth, and once the polling actually finds out that the processing is done, this statically rendered flag from the backend is suddenly "out of date", meaning you'd have to ignore it completely once onProcessingComplete fired.

The technical problem is that within the body of onProcessingComplete, you're reloading the live-queried version of the registration, which lives much higher in the DOM tree and thus causes a full re-render. The re-render then tries to take this "outdated" backend information back into account.

I can see two solutions, with neither of them being overly amazing:

1. Introducing another "tripwire" style state that gets set to true once the onProcessingComplete hook actually fired, and when that tripwire state is true, the isProcessing flag from the backend gets fully ignored. Basically a short-circuiting mechanism. Nasty hack but works.
2. Moving the current, frontend-only processing state (the one created by the useState hook) up several levels to the same place where the registration is queried. That would mean you have to pass the setProcessing setter down several levels to be able to use it in the onProcessingComplete hook, which is also nasty. But at least it would avoid the re-render logic and you could then indeed just initialize useState with the backend value as indicated above.

The ideal solution (which requires significant effort though) would of course be to move everything into a shared useContext state that can be pulled in on-demand, completely making these render dependencies obsolete.