ここで書いてること

• タイトルの構成でWebアプリ作った際に思ったこと
  • 作り方ではないのでコードは一切書いてない
  • 作り方的なのも書きたいけど多分無理

きっかけ

• 2016年は結構ダラダラしてた
• 仕事以外ではほとんど何も書いてない
• 夏以降は筋トレのことばっか考えてた
• おかげで筋肉はついたよ
• そろそろ何か始めようかと思った

何を作ったか

• 何をはさほど重要ではなかった
• 今回重視したのは何を触るか
  • Redux(Flux)
  • React
  • Webpack
  • Firebase
  • postcss
• 結局作ったのはメモ帳でした

Redux

• ReduxというかFluxでちゃんと作ってみたかった
• Reduxのチュートリアルはやった
• 公式ドキュメントは読んだ
• Fluxを調べる内に@azu_reさんの10分で実装するFluxに辿り着いた
  • これで良いじゃない
  • Fluxの実装面をちゃんと理解して書ける
  • 別にReduxを使わなくても小規模だったらいけんじゃないか
• 結果mini-fluxをベースにReduxの良いと思った思想を突っ込んだ形に
  • actionにはtypeを必須にする
  • アプリは1枚のstateで管理する

思ったこと

• 語り尽くされてる気はするけど、処理の流れが一定なの凄く良い
• 流れを追いやすい

以下の流れで機能を作って行けば良いのでリズムよく書ける
1. actionType作る
2. action作る
3. コンポーネントのイベントでactionを実行させる
4. storeに送る
5. state変更
6. アプリのstate変更
7. viewが変更

• 変更に強い
  • 上記の流れを足して行けば良いだけ
• とは言え困ることもある
  • 上記流れに反する処理はどうすれば良いのか
  • 例えばstoreで変更されたstateによってactionが発生するみたいなパターン
  • view->action->store->view ではない
  • しょうがないしstore->actionもありだと思うことにした
• store, actionを1つのクラスにするので1ファイルにダーっと書かないといけない
  • めっちゃ長い
  • 分割しようとしたら何か黒魔術感ある記述になった
  • this.__proto__[methodName] = method;
  • this.__defineGetter__(val.name, val.getter);
  • this.__defineSetter__(val.name, val.setter);
  • これ使ってて大丈夫なのかな感ある
  • combineReducerっぽい感じのことやってる
• やっぱり段々Reduxみたいになってくるんじゃないかこれ
  • 複数人で作る場合は統一した何かがある方が良いしそこはライブラリのwayに乗る方がよさそう

React

• 特に理由は無い
• スタンダードだしなーくらい
• vue.jsはもちょっと後でで良いんじゃないかな
• 前にReact試したときは基本バケツリレーやってたからアホらしくなったんだけどFluxに入れたらどう感じるかなってのもあった
• やっぱ独特なとこはあるけど概ね不満なく

思ったこと

• React自体で困ったことはそんなに種類はない
• stateの条件によって表示するDOM出し分けたい時どうしたら良いのとか最初よく分かんなかった
  • Conditional Rendering - React
  • 結構大胆な書き方。。
• renderが走ってる最中にstateを更に書き換えた場合エラー出る
  • reduxはそういうの上手くやってくれてるんじゃないかって気がする（知らない）
  • 自前で書いてるわけで、そんな機構書いてない
  • 1つのactionでstateを複数書き換えるような事がないように頑張る
  • どうしても出るならstateの変更を上手いことまとめる処理が必要になりそう
• Class Components、Functional Components どっち書けば良いの？
  • シンプルなコンポーネントだったらFunctionalで書けば良いじゃないとのこと
    • State and Lifecycle - React
  • 実際this書かなくなったりbind書かなくなったりでシンプルになって良い感じではある
  • コンポーネント自体にstateを使わない場合はFunctionalで書ける
  • statelessなのでcomponentWillMountとかのlifecycle系が使えないので使う場合は普通にES6classで書こう

webpack

• ずっとbrowserifyだったんだけどまぁ使ってみるかー程度
• ちょうどバージョン2も出たしね
• cssはpostcssを単独のファイルにするやり方
  • css in JS は何となくやってない
  • やろうと思えばすぐやれるようにはしてる（はず）

思ったこと

• 全部入り的なのはやっぱり楽

Firebase

• 今回の目玉
• サーバ側は基本的にやらないので楽したい
• ユーザー認証とか作りたくない
• デプロイもやってくれるの楽
  • 独自ドメインでやりたい時は一手間増やせば良いだけっぽい

思ったこと

• 何だかんだRDBMSしか知らないのでNoSQLタイプのデータ構造の作り方を理解するのは時間かかった
  • 公式の動画が一番良い気がする
  • The Firebase Database For SQL Developers
  • これは多分全部見た方が良い
• ユーザー認証マジ便利
• Firebase自体の機能とか思想とか理解するのは時間かかったけど、自分でバックエンド作るより何倍も楽

PostCSS

• 果たしてsassに取って代わる感じになれるのか試してみた
• なのでcss in js はやってない
• 次はやってみようかと思う
• 結果、sassでやってたことは大体できるようになった
  • cssnext (variables)
  • postcss-import
  • nesting
  • mixin
• 変数はcssnextのvariablesに記述を変更
  • mixin使うからpostcss-simple-varsも使えるんだけど自分で書く場合は使わない
  • できれば標準になると思ってるものだけ使いたい
  • ただしmixinとネストはないとヤだから気にしない
• エディタの補完とか効かなくなったりエラー判定されたりするのちょっと困る
  • そもそもmixinとかは独自の機能だからしょうがない気もするけど悩ましい

思ったこと

• sassを置き換えるなのかbabel的に未来を先取りするのかの立ち位置を決めておく必要がある
  • sassの機能が全てcssに入る保証はどこにもないのでどっちもってのはあり得ない
  • 今回はsassを置き換える方にしつつ、標準で付きそうな機能はそっちを採用した
• 置き換え自体は概ね成功してるからもうこれで良いんじゃないか感ある
• npm installしたfont-awesomeのインポートが上手く行かなかったから別途htmlから読み込んだ
  • これはいつか解決しようかなーとは思うものの一旦走りきった今やる気力がない

実際に作ったもの

• worcar
  • word card
  • GitHub
• 今年は英語を頑張ると決めたので、英単語帳を作ろうかと思った
• 何も知らない人が使うようには全くできてない
• UI決めるのが面倒だったのでMacアプリのQuiverの見た目をまねた。パクったとも言う
• Markdownで書けるやつ
  • react-markdown
• 実際出来上がったものを見たら全然英単語帳じゃなくなってた
  • 簡易なメモ帳でしかない事実に驚愕
  • 自分で使うにあたり最低限の機能はできたからまぁ良しとしてる

作ってみての総論

• Firebase使うと基本的にフロントの事しか考えずにWebアプリが作れるのは嬉しい
  • 今までしてたバックエンド作れないからとかの言い訳が効かなくなったね
• React + Flux 冗長だなって気持ちもあるけど流れがシンプルだからさほど気にならなかった
• 延々増え続けるPackage.jsonのDevDependencies
• 我々は何個.xxxrc系を書けば良いのか
• 今回Redux,Reactのドキュメントは原文を読んでみた。分からん事も多かったけど概ね何とかなった気がする
• 作るのは楽しい