3/2 独自のツールを構築する #tryswiftconf
try!Swiftのセッションまとめシリーズです。Orta Theroxさんの「Building your own tools」についての記事になります。
資料
公開されていないようです
内容
- Swiftとは別の話をする
- 問題
- 開発、ビルドに時間がかかるようになっていた
- 3人で開発していた
- カスタムViewControllerがいっぱいあった
- webと同じ速度で開発するのは厳しい状態に
- コードの再使用ができない状態になっていたことが原因
- 変更しようと思うとコンパイルサイクルが長くなっていた
- ネイティブのデザインパターンを考えた
- 最初に考えたデザインパターン
- Reactに影響を受けてKATANAを作ろうと思った
- コンパイルをすくなくすることが解なのかもしれない
- React Nativeやってみようという話になった
- JavaScriptで書いたらどうなるかの実験
- Swiftの抽象化をやってみようと思った
- Swiftコードはドメイン固有に
- 再利用できない
- React Nativeは素晴らしかった
- 既存のViewControllerのコード量が減る
- Reactで書くか、書かないか
- Swiftのメリット
- AppleがSwiftを使いたいということでプッシュしている
- Swiftのデメリット
- React Nativeのデメリットは？
- 依存性が593も出てくる
- 若い技術なので大手の数社しか使っていない
- 目まぐるしく変わっている
- React Nativeのメリット
- 実践的に作られている
- 全ての問題を解決してしまいそうだが、そう願うべきでもない
- API思考アプリにはすごくいい
- 全てのJavaScriptは異なるスレッドで実行されている
- ブロッキングコードを書くのはとても大変
- フレックスボックスモデルを使っている
- テスト
- jsはネイティブテストより進んでいる
- クリエーターの方とコミュニケーションを取って作っていくことができる
- モバイルチーム
- 同じパラダイムをwebチームと共有している
- 全てがフォーク可能
- 自分たちのコードが持てる
- 弊害は時間と専門知識
- jsはひどい言語と言う
- jsは10日で言語が開発されている
- でも型、オプショナルがあるTypeScriptだってある
- 結論
- 自分たちのプロジェクトはReact Nativeが理にかなっている
- Reactとは何なのか
- データは下方向のみに流れる
- webページでviewヒエラルキーをマスキングしようということからはじまった
- React Native
- 関心の分離
- prpsを使う
- データのimutableなもの
- relayは素晴らしい
- exportを除いていく
- relayそのものを含める必要がある
- file privateクラスになった
- ツール
- より適したツールを発見してきた
- 作ってもらいたいアプリに有利に傾いている
- Swiftはアプリを安全に構築できる
- Appleは安全性が大事
- Xcodeの外に目を向けるべきかも
Q&A
React Nativeの開発でアニメーションをするのはどれだけ大変なのか
- そういったアプリに向いているかどうかはわからない
- どの程度のものかということも関係してくる
- 綺麗なアニメーションの場合はReact Nativeは使わないかも
React Nativeは全部のアプリケーションで使うのか、一つの機能エリアで使うのか。ハイブリッドにできますか？
- ポッドを構築した
- 全てのReact Nativeが中にある状態
- 大きな複雑なアプリであれば実行可能である
- 自分たちはライブラリのような使い方をした
その他このトークに関する情報源
- 独自のツールを構築する | try! Swift Tokyo 2017 #tryswiftconf Day1-14 聞き起こし - niwatakoのはてなブログ
- try! Swift 2017 Tokyo に参加してきた - 2. 1日目 - My Favorite Things - Coding or die.
- [速報レポート] try! Swift TOKYO 2017 1日目 午後II #tryswiftconf ｜ Developers.IO
