前提条件

以下の構成のアプリケーションを想定しています。

ビルドツールに Leiningen を使用
material-ui は cljsjs/material-ui を使用

props が変化する度に withStyles を利用して生成したコンポーネントが再マウントされてしまう

withStyles を利用したコンポーネントをレンダリングする度に再生成している場合、 withStyles から生成されるクラス名が再生成の度に変化するためコンポーネントが再マウントされてしまいます。

以下のように一度だけ withStyles を利用してコンポーネントを生成させるべきです。

Bad

(defn approach
  [props]
  [(r/adapt-react-class ((mui/with-styles approach-styles) (r/reactify-component approach-component))) props])

Good

(def approach
  (r/adapt-react-class ((mui/with-styles approach-styles) (r/reactify-component approach-component))))

また、そもそもとして withStyles のような Higher-Order Components を利用してコンポーネントを生成する場合、 render メソッド (reagent で言う　(defn hoge [props] [...]) 相当) 内での生成はコンポーネントの再マウントを招くのでReact 公式ドキュメントでも非推奨とされています。

このハマり方をした人はおそらくReagentのドキュメントを見てそれに習った方だと思うので、誤解のないようにドキュメントの修正PRを出しています。
↑この記事の投稿前にドキュメントの修正PRがマージされました

SSR を行っている場合、 hydrate 時にコンポーネントが再マウントされてしまう

公式ドキュメントに従ってSSRを行っていながらこの状態となる場合、サーバーサイドとフロントエンドで設定されている process.env.NODE_ENV が異なっていて生成されるクラス名が変化している可能性があります。

特に、通常 process.env.NODE_ENV はビルド時の環境変数によって変化するものですが、cljsjsのライブラリを利用している場合はその限りでなくライブラリに既に値が埋め込まれており、 :optimization が :none の時のみ 'development' 、それ以外は 'production'で固定 となります。

ここについては ClojureScript のドキュメントに書かれている通りで、読み込まれるライブラリが :optimization によって別のファイルになる事に起因するものなので、 process.env.NODE_ENV = 'production' でもコードは最適化しないと言った事は事実上不可能です。（そもそもここで議論されている通りサーバーサイドでもコードの最適化をしていなければパフォーマンス的に不利益を被るため、やること自体にメリットはないかも知れませんが）

つまり、本番用ビルドの場合はサーバーサイドも {:optimization :simple} か {:optimization :advanced} に設定しておく必要があります。