Refactor VisualMatchingPairs

[BeritJanssen]

@drikusroor , I've been wondering if we can refactor VisualMatchingPairs so it can actually be run through the MatchingPairs component instead, bringing down the number of components, and also the amount of verbatim repeated code in the frontend. Differences between the visual and audio version

• different Preload (this is controlled through the play_method, so that's already taken care of)
  ...

Can you specify more differences? Or provide comments for any difficulties you might foresee? I'm asking because in this case we could also bring back the rules files to just the one ("Fieldwork") one, of which we could make different experiments in the admin interface, one of which would be coupled to a "Playlist" of image files.

[drikusroor]

My idea was originally to rewrite the logic of the game in a simpler and more readable way for VisualMatchingPairs and that we could later use that code for MatchingPairs as well. But now that I look at VisualMatchingPairs I don't feel I've succeeded in doing that. 😂 The other differences are the elimination of useRef and the use of a click handler on an overlay instead of through adding a click event listener that goes outside of the component.

However, I don't feel like we have to combine these two components per se. I'm all for DRY, but I'm also all for WET (Write everything twice), and this situation is a tricky one. If we were to combine them into one component, I think it would be a good idea to create a logic component and a visual component. The visual component would then just render the template according to the state passed along in props and would only send back click events. The logic component would then decide what to do with those events. Both MatchingPairs and VisualMatchingPairs are already full with useEffect hooks and I would like to keep it readable, if possible.

[BeritJanssen]

I'm now actually already running into an issue with the duplication: VisualMatchingPairs does not understand the score_feedback_display setting.

[BeritJanssen]

What's the advantage of WET?

[BeritJanssen]

With the additional problem of not being able to reuse intermediate_score on the backend component, I'd really vote for refactoring to one component.

[BeritJanssen]

See #796 .