Add persistor to pset components

[MReyna12]

No description provided.

[MReyna12]

Notes:

1. For the multiselect interactive: In order to use an array inside of the useEffect dependency i wrapped it with JSON.stringify(). Per this discussion it looks like this is a viable option in our scenario, but I am open to another solution either outlined in the discussion or somewhere else.
2. All PSET interactives:
   a. Error handling on failed put - Currently, I am only using console.error(err). Because the put occurs outside of the handleSubmit, I do not think I can use setFieldError in the same manner as UserInputBlock.tsx. Any ideas on how to handle a put failure?
   b. I believe we need retriesAllowed and formDisabled/inputDisabled as a dependency of the useEffect. I've also included response as a dependency, but response updating occurs when retriesAllowed and formDisabled/inputDisabled updates as well. Should we include response as a dependency or would retriesAllowed and formDisabled/inputDisabled be sufficient?

[rnathuji]

@MReyna12 - This is a partial review of just ProblemSetBlock and InputProblem. The reason being, depending on thoughts there it would impact the other components in a similar way. See what you think about my thoughts, but I believe they would address both of the items you raised here:

• Item 1: It would remove the pattern of using state as in the useEffect dependencies altogether
• Item 2: The .put() would get moved into handleSubmit() so we could employ the same error handling pattern we have in UserInputBlock.

[MReyna12]

@rnathuji - My latest commit addresses your comments. I am still trying to see if there is anything that can be done in the submit handler to not effectively write the same try/catch statement three times (unless you think it is not necessary). Once these updates get approval I will make similar updates to the other components.

[rnathuji]

@MReyna12 - I think the changes to InputProblem in general look good and can be replicated across. I don't see an obvious way to avoid the multiple try / catch statements, and perhaps that's something we can just defer to a future "real" implementation since what you have does address the key pieces. I did have a few comments on the new handleFeedback().