remove UNSAFE component function and clean up state

[walesch-yan]

This PR removes the UNSAFE_componentWillRemoveProps function from SampleImage. The function did two things previously:

• resetting the image ratio to match the canvas element in case the image width changed: This was moved to componentDidUpdate
• resetting the scale of the GridPlugin. This is actually already called every time the component updates (plugin is updated in the render function) and could safely be removed.

Furthermore, there were additional checks for cinema and autoScale modes. However, toggle actions existed to change the corresponding states, but were never triggered in the code (they always equaled the initial state value). Since, this was the only place where those state variables were used, I removed them from the state as well as the actions

[walesch-yan]

I saw that this action was also never called, so removed it. Instead there is an action called setVideoSize which is used by mxcube, to change the above parameters.

[walesch-yan]

I'm not super happy myself with this solution, as it will trigger 3 re-renders when the video size changes (Which was in fact the initial behaviour). This is somewhat reletad to the fact that imageRatio prop in this component does not equal imageRatio from the state, but imageRatio * sourceScale. I think that there might be a way to improve this, but it would need some more investigation. Here I went with the easier implementation that keeps the previous behaviour but removes the unwanted UNSAFE function

[axelboc]

Replacing UNSAFE_componentWillReceiveProps is a really great first step. 👍

This imageRatio business rings a bell actually. Seems like the Redux store should maybe hold on to clientWidth instead of imageRatio so that the ratio can be recomputed where needed in the component. EDIT: this would in fact get us closer to a modern solution with a useMeasure hook.

Alternatively, I wonder if just recomputing and setting imageRatio inside the SAVE_IMAGE_SIZE case of the reducer would do the trick. 🤔

[walesch-yan]

Actually, the imageRatio from the state represents the clientWidth of the outer-wrapper of the SampleImage. The SampleImage container calculates scale * clientWidth and passes this result as imageRatio (definitely a naming problem 😅 ) prop to SampleImage.

One have to keep in mind that when the scale resp. the size of the original image changes, the size of the wrapper element will change as well, but since it is rendered within the SampleImage component the clientwidth will only update after the component mounted, which will then in turn trigger another re-render, since the state for the clientWidth (i.e. imageRatio). There will also be a final re-render afterwards, for the check, so that makes 3 renders for a change to the scale value coming from SAVE_IMAGE_SIZE.

I think, as you mentioned, having something like useMeasure might be ideal here.

[axelboc]

imageRatio is computed to clientWidth / state.width in the reducer when the SET_IMAGE_RATIO action is dispatched:

mxcubeweb/ui/src/reducers/sampleview.js

Line 97 in 2050f23

return { ...state, imageRatio: action.clientWidth / state.width };

That's the computation that is making a lot of things more complicated than they need to be, I think (and why I'm arguing for storing clientWidth in the state instead).

But I get your point about having to remeasure the container after changing the image size and after re-rendering SampleImage. This definitely requires either componentDidUpdate with a width check or a ResizeObserver to be set up on the container (as would useMeasure do).

[axelboc]

Fantastic!

[axelboc]

Replacing UNSAFE_componentWillReceiveProps is a really great first step. 👍

This imageRatio business rings a bell actually. Seems like the Redux store should maybe hold on to clientWidth instead of imageRatio so that the ratio can be recomputed where needed in the component. EDIT: this would in fact get us closer to a modern solution with a useMeasure hook.

Alternatively, I wonder if just recomputing and setting imageRatio inside the SAVE_IMAGE_SIZE case of the reducer would do the trick. 🤔