Reactというフレームワークに魅入られ**『いつか業務で使ってみたい!』**と焦がれ幾年。
巡り巡ってようやくReact開発のプロジェクトに出会えた際に感じた事を、記事にまとめようと思います。
筆者について
- Webエンジニア
- 業務ではjQueryでDOM操作ゴリゴリというプロジェクトを転々
- React自体は未経験ではなかった
- v14辺りから個人的な学習は重ねていた
-
業務での利用経験はゼロ
タイトル詐欺?🤔
-
業務での利用経験はゼロ
プロジェクトについて
- (当然)Webアプリケーション開発のプロジェクト
- バックエンドはPHP
- 業務系のBtoBなアプリケーション(not SPA)
- 他メンバーは筆者と違い、ReactやモダンなJSフレームワーク自体が完全に初体験
経緯
- 参画当初、具体的なフロントエンドのアーキテクチャは決まっていなかった。
- 『jQueryで作ろうかなー、なんか他にイイのある?』くらいの温度感
- Reactを提案してみる → あっさり『イイね!みんなで勉強しながら使ってみよう!』 となる(許可、検討頂いた関係各位には感謝しかありませんm(_ _)m)
導入してメリットに感じた点
state管理の素晴しさ
DOMの操作は必ずstateの変更を経なければいけない、というReactの制約はjQueryに慣れた身には窮屈に感じる場面が多々ありました。
しかしその窮屈さを乗り越えた先にあったものは、jQueryやテンプレートエンジンでは得難い、動的なWEBアプリとしての『堅牢さ』でした。
どんなWebアプリも動的である以上、状態を持つ事は免れません。
- 検索結果の一覧表示 → 『検索結果という状態』によって増減する一覧の表示
- 管理者権限でのみ表示されるボタン → 『権限という状態』次第で表示されるボタン
ReactやVueでは動的項目を全て**状態(state)**とみなし、状態の変化をトリガーにし、変化した状態を元に自動でDOMを組み替えていきます。
『状態変化後に、別途DOMを組み換えるロジック』を自前で実装する必要がありません。
function Example(props) {
const [list, setList] = useState([]) // 初期値は空配列
const [isAdministrator, setIsAdministrator] = useState(false) // 初期値はfalse
// 『setList』と『setIsAdministrator』に値をセットするだけで、下記のDOMが自動で書き変わる
return (
<div>
{* データ一覧表示 *}
<table>
<thead>
<th>ID</th>
<th>名前</th>
<thead>
<tbody>
{list.map(item => (
<tr>
<td>{item.id}</td>
<td>{item.name}</td>
</tr>
))}
</tbody>
</table>
{* 管理者権限のみ表示されるボタン *}
{isAdministrator ?
(<button>承認</button>) :
(null)
}
</div>
)
}
画面をフルレンダリングさせた上での動的な表示制御であれば、jQueryやテンプレートエンジンのみでも問題無く実現出来ますが、非同期通信を用いた動的な表示制御となると一変して、いちいちフラグ格納用の隠しDOMを用意したり、作りにもよりますがサーバーサイドでセッション領域にフラグとなる値をフラッシュしたりしなければならず、更に状態の変化とワンセットで、DOMの組み換え処理を自前で必ず『忘れずに』実装しなければなりません。
<!-- こんなDOMを用意しておいて・・・ -->
<table id="hogeTable">
<thead>
<th>ID</th>
<th>名前</>
</thead>
</table>
var tbody = $('tbody')
//『list』変数には非同期処理等で取得したデータの配列が格納されている
$.each(list, function(index, item) {
tbody.append(
$('<tr>').append(
$('<td>').text(item.id),
$('<td>').text(item.name)
)
)
})
$('table#hogeTable').append(
tbody
)
// 手続き的で、これだけの構成でも実装が結構しんどい…
// →DOMの構成が少しでも変わると大事
状態を持ったアプリを作る以上、ReactやVueの様な状態管理の仕組みが無ければ、要件が変わって状態が1つ2つと増えていくうちに【条件判定 & DOM組替】のロジックがどんどん膨らんでいき、バグのリスクが急激に跳ね上がってあっという間に脆弱なアプリが出来上がってしまいます。
シェアが多いので文献が豊富
シェアが少ないフレームワークやライブラリは、ググってもまともに情報が出てこない、というケースが多々あります。
公式のリファレンスもあまりメンテナンスされておらず、いまいち不親切な書きっぷりの物も多いです。
ReactやVueであればシェアが非常に多い分、調査の結果解決策にたどり着きやすく、何より公式のリファレンスが非常に充実しており、技術的な問題に直面した際の安心感が段違いでした。
チーム全体におけるソースコードの品質が同じ水準になっていった
state管理から始まり、Reactは厳しさとも取れる制約を強いてくるフレームワークです。
- DOM操作は絶対に状態(state)の変更を経る
- DOM操作ではない、DOM『参照』においても、必ずstateを参照しなければダメ
const hoge = documen.getElementById('hoge').value; // ←ダメ
- マークアップの閉じ忘れは絶対にNG(トランスパイルが通らなくなる。
<br>
とかもダメ、絶対閉じる →<br/>
)
...等々
しかし、それらの厳格さの元に出来上がったソースは、チーム全体で似たような書きっぷりになっていき、気づけばスキルもキャリアも全く違う各員が、同じ目線、同じ思想を持ってソースコードが書ける様になっていきました。
楽しい
個人的にはこれが一番のメリットに感じました。
チームには、私より経験豊富なベテランPG、今回が初現場という新人PG等、幅広いキャリアのメンバーが揃っていましたが、Reactの基礎的な仕組みを理解頂いてからは『state変更を通じて、DOMをコントロールしている感じが面白い』『Reactを使って綺麗にソースを書いていく事が楽しい』という声が上がって来る様になりました。
メンバー全員にReactの思想の素晴らしい部分や、何よりReactを用いたプログラミングの楽しさを伝える事が出来て、本当に嬉しく思いました。
『楽しさ』はそのままパフォーマンスの向上に繋がり、作業効率や出来上がった機能の品質にそのまま直結していきました。
導入してデメリットに感じた点
学習コスト
従来の手続き的なDOM操作から、Reactの宣言的なDOM操作というのはかなりのパラダイムシフトで、私自身も過去に詰まった点等は、極力わかりやすくメンバーにお伝えしたつもりでしたが、それでもやはり導入して2~3日はまともにパフォーマンスが発揮できたメンバーはいないという状態でした。
ですが、前述のメリットの通りその分も遅れも十分ペイ出来るのパフォーマンスを、最終的にはチーム全体で発揮できたので、とりあえずは結果オーライだったのかな、と思っています。
ブラウザバックの制御が(若干)面倒
開発するWebアプリにおいては、ブラウザバックが正しく動作する、という要件は満たす必要がありました。
私自身は過去にreact-routerを利用して、学習がてら簡素なアプリのブラウザバックの機構を実装した事はあったのですが、業務での利用は初めてだったので、要件通りに機能を満たせるか、不安に感じていた点ではありました。
結果react-router並びに、react-routerが提供してくれているhooks API(v4~)を利用する事により、旧来のバージョンのreact-routerに比べて、更に簡潔な記述でブラウザバック動作の処理を実現させる事が出来ました。
しかしブラウザバックを検知するhistoryによるlisten周りの処理は、コンポーネント内に副作用として記述せざるを得なかったので、やはりSPAフレームワークによるブラウザバックの制御はしんどいものがあるな、と改めて実感しました。
まとめ
ReactはSPAを作成するフレームワークである、という認識も根強いかと思いますが、state管理というパラダイムはSPAに限らず、『多様な状態』を持つ業務系のアプリケーションにおいても十分に有用であると感じました。
jQueryやテンプレートエンジンが一様に劣っている、という訳ではありませんが、ReactやVueが持つ技術的なパラダイムは、jQueryや旧来のテンプレートエンジンでは応えきれなくって来た、昨今のユーザーがWebアプリに求める多様な要件に対する解の一つである、と感じました。
さぁ、業務でjQueryしか触ったことが無いというアナタも
今すぐ環境構築をしてLet's Reactライフ!