Make clicking a DOM <input> ref React.StrictMode compliant

The component below is used to trigger opening a file input dialogue in desktop browsers and opening the camera on mobile devices. It is attached high in the component tree and is thus mounted once at startup, so the input DOM element is (in production) permanent. In React.StrictMode the component will trigger opening the file dialogue twice. This is fine - I know what strict mode is, but I am unsure how I can change the component to avoid triggering the input twice. We click the file input in the shouldComponentUpdate method and I guess there should be some kind of cleanup done to avoid this happening twice. The thing is, I thought we were doing this cleanup already, by triggering closeCamera(), which is dispatching an action that ends up changing state in our Redux store, so that eventually props.openedBy is set to null. This works fine in non-strict mode, so there is something I am missing ...

export class CameraTrigger extends React.Component<Props, State> {
  static defaultProps = {
    openedBy: undefined,
  }
  fileInputRef: React.Ref<any>

  constructor(props: Props) {
    super(props)
    this.fileInputRef = React.createRef()
    this.state = {
      lastOpenBy: undefined,
    }
  }

  /**
   *  Redux camera.openedBy state is changed to null immediately after displaying file selection window.
   *  Thanks to that we are sure that we have clear state regardless of the canceling or actual image selection.
   *  But we need to keep the information about opener to pass it to the saveImageFileAsObjectURL a short while later.
   */
  static getDerivedStateFromProps(props: Props, _state: State) {
    if (props.openedBy) {
      return {
        lastOpenBy: props.openedBy,
      }
    }

    return null
  }

  /* we never re-render the input button */
  shouldComponentUpdate(nextProps: Props, _nextState: State) {
    const { openedBy } = nextProps

    const ref = this.fileInputRef
    if (openedBy && ref) {
      ;(ref as any).current.click()
      this.props.closeCamera()
    }
    return false
  }

  clearInputBeforeNextUpload = (input: HTMLInputElement) => {
    input.value = ''
  }

  fileInputChanged = (event: React.ChangeEvent<HTMLInputElement>) => {
    const input = event.currentTarget as HTMLInputElement

    if (input.files && input.files.length) {
      const file = input.files[0]

      this.props.handleImageFile(file, this.state.lastOpenBy, this.state.lastEncounterId, this.state.lastConversationId)
      this.clearInputBeforeNextUpload(input)
    }
  }

  render() {
    return (
      <input
        name="message-file-upload"
        type="file"
        accept={MimeTypeMap.JPEG}
        capture="environment"
        ref={this.fileInputRef}
        onChange={this.fileInputChanged}
        style={{ display: 'none' }}
      />
    )
  }
}


type Props = {
  handleImageFile: Function
  closeCamera: Function
  openedBy?: string
}

type State = {
  lastOpenBy?: string
}

I found out what was wrong and why through inspecting the React docs on pure vs impure functions.

In the older React docs on StrictMode, they have a section called "Detecting Side Effects" that talks about the render phase vs the commit phase, and that functions that are called in the render phase should be pure. Purity in this context means avoiding side-effects:

> Because the above methods might be called more than once, it’s important that they do not contain side-effects. Ignoring this rule can lead to a variety of problems,

and it lists the following functions as being called in the render phase

> Render phase lifecycles include the following class component methods:
>
>- constructor
>- componentWillMount (or UNSAFE_componentWillMount)
>- componentWillReceiveProps (or UNSAFE_componentWillReceiveProps)
>- componentWillUpdate (or UNSAFE_componentWillUpdate)
>- getDerivedStateFromProps
>- shouldComponentUpdate
>- render
>- setState updater functions (the first argument)

The (new) docs also say:
> To help you find accidentally impure code, Strict Mode calls some of your functions (only the ones that should be pure) twice in development

In the list that follows, it includes shouldComponentUpdate.

What this means is that my side-effect above, called in shouldComponentUpdate must be moved to another function that is called outside of the render phase. The correct (at least one way) method seems to be componentDidUpdate. As the docs state:

> You can use it to manipulate the DOM after an update. This is also a common place to do network requests as long as you compare the current props to previous props (e.g. a network request may not be necessary if the props have not changed). Typically, you’d use it together with componentDidMount and componentWillUnmount:

Simply moving the click-invoking to componentDidUpdate fixed the issue for me

and that removed the issue for me. Here's the diff

-  /* we never re-render the input button */
-  shouldComponentUpdate(nextProps: Props, _nextState: State) {
-    const { openedBy } = nextProps
-
-    const ref = this.fileInputRef
-    if (openedBy && ref) {
-      ;(ref as any).current.click()
+  componentDidUpdate(_prevProps: Props, _nextState: State) {
+    const ref = this.fileInputRef as { current: HTMLInputElement }
+    if (this.props.openedBy && ref) {
+      ref.current.click()
       this.props.onTrigger()
     }
-    return false
   }