はぜにっき

日記です。(毎日更新ではない)

日記: SPAでリロードしたら404になる問題, その他

トップページ以外でリロードしたら404になる現象が起きて、ちょっと考えたら、まあそうだよなってことですぐ解決した。

/works にダイレクトアクセスしたときに、それに対応するファイルが存在しないとindex.htmlに届かずにnginxに404で弾かれる。
冷静に考えたら当たり前だけど、react-routerが勝手にやってくれるやろって思って考えてなかった。
その手前で死ぬのか。なるほどな〜ってなった。

トップ( /index.html )のリンクを踏んで /works に遷移するとreact-routerがルーティングしてくれて、index.htmlの div = root のまま更新する分のコンポーネントだけ再描画してくれるから問題が起きなくて、リロードだけ問題になる。この説明であっているかはわからない。。。

ちなみに、create-react-appで作っている途中だと、 webpackDevServer.config.jshistory api foolbackの設定が書かれていて気付かない。nginxもかまさないし。

[nginx.conf]
...
        location / {
            try_files $uri $uri/ /index.html;
        }
....

try_filesは、最初の引数から順番にパスに合致したファイルが存在するかを確認するやつで、
$uri はそのまんまURL, $url はURLに / を追加したもの
それらが存在しなかったら、 rootdir/index.html を探しに行くっていう流れになる。(当然そのindex.htmlもなかったら404になる)

この辺の設定、あんまりちゃんと理解せずに適当にコピペしたりしていたけどそろそろちゃんと中身理解しておかないと変なところで躓きそう。気をつけよう。


wakateweb.connpass.com

若手エンジニアイベントで雑にLTした。LTすることを2日前まで忘れていて急いで資料を作ったら、7分の発表なのに30枚オーバーとかになって頑張って削った。
なぜか偶然前職の人がいたり、若手(なのに)でPerlを書いたことがある人が多かったり、色々あって面白かった。

市場価値と自分の技術に対する興味 - はぜにっき
前の記事にも書いたけど、大きな技術特化のイベントとかで話せるようなぐらい専門的な知識をつけたいなあって一瞬思ったりした。
でもその前に、仕事にも影響が出ている設計周りの知識と実感(?)の無さ、頭のついていかなさをなんとかしないといけないなーっていう気持ち
がんばろう

ポートフォリオサイトを作り直した

f:id:hazeblog:20181111232016p:plain

一気に素っ気なくシンプルなページになってしまった。


github.com

こんばんは。はぜです。

プロフィールページみたいなものを作った(仮) - はぜにっき

フロントエンドの知識が全くなくてつらい - はぜにっき

半年以上前に作った haze-page.tokyo というポートフォリオサイトをSPAにしてみました。
アイコンとかサイドバーは semantic-ui-react を使った。知ってる人は一瞬でわかると思う。

create-react-app-tsをejectして、 semantic-ui-react入れて、react-router, react-router-domを入れて中身書いたら終わった。
2時間ぐらいで出来ると思って日曜日の昼から手をつけ始めたら、思ったより自分がCSSを理解していなくて、重ねて表示ができなくて困ったり、意味わからん場所にテキストが表示されたりした。
ぐぐりながら脱線したり、戻ったり、semantic-ui-reactをうまく使いこなせずに気付いたら22時過ぎ。つらい1日だった。。。

create-react-app, デプロイの方法を全く調べずに作っていて、できた瞬間にやり方わかんねえ〜〜ってなって困るなど。
npm run build して、buildファイルをサーバに投げて、nginxのrootディレクトリ設定変えただけで終わった。最高。

jestとか、その他諸々の全く使っていないライブラリをどうにかしたい。
というか使えるようになりたい。

とりあえず頭に浮かんだ画面をどうやって描画していくか、の練習になったのでよかった。
次はAPIを叩いたり、他のライブラリを使って良い感じのサービスを作りたい。API設計とかまともにやったことないからそこらへんも調べたり練習しなければ。。。

市場価値と自分の技術に対する興味

「エンジニアとしての市場価値を上げるために、今自分に足りていないこれを勉強しよう」っていうの、出来ないんですよね。
社内の誰にも負けない範囲の能力が一つ以上あると存在価値が上がるだろうし、
それこそ本を出したり発表をしたりできるようなレベルだったら会社をやめたとしても他の会社でも同待遇で雇われることができたりするだろうけど。

なんというか、組織の課題を解決する・目標を達成するために自分に足りていないものを習得するのはできるんだけど
自分の市場価値を上げるためにとか、エンジニアとして自分が強くなるために、みたいな発想にならない。

一応、技術者として仕事しているからあんまり言わないようにしているんだけど、
自分自身はあんまり好きな技術っていうのとか、好きな言語とかって特になくて、
課題を解決するための仕組み(=サービス)を作ったり、目的をどうやって楽に達成できるかを考えて、その時その時で必要な技術を習得してる。

最近はバックエンドエンジニアとして入社したけど、フロントエンドも見れた方がサービス・開発組織全体を俯瞰して見れそうっていうことでReactを触り始めていたり、
単純に機能開発で必要になるからRailsを触っていたり、社内のソースコードを読んだり、GraphQLがわからんって言ってる。

でもそこまで深い興味があるわけでもないから、rails/railsのソースを読もう!って気持ちには全くならないし、メンテナになりたい!とは思わない。
オープンソースコミュニティへのコントリビュートは自分ができる範囲でやりたいとは思ってはいる。これは単純に自分のためというより、感謝の分を返したいという気持ちから)


なんでこんなこと書いてるかっていうと、
最近Microservicesやアーキテクチャ周りに興味が強くなっていて、なんでだろうなーって考えて、
プロダクト開発をする上で、変更に対する影響範囲を小さくして安心したものづくりをできるようにする、一つの機能の開発速度を上げるようにできる仕組みを確立することで、
最初の方に書いた目的の達成や課題解決に繋がるからなんだろう、ということな気がしたから。

Microservicesっていう技術や、各種アーキテクチャそのものに興味があるわけではなくて、それを使うことでどれぐらい開発が早くなるのか、改修が楽になるのかを知っていきたいっていう結論になった。


とは書いているんだけど、一個一個の技術に対して深く興味が沸いてないのって、深く技術を見れるほど精神的な余裕がないっていう現れなんじゃないかなあと感じたりしている
自分の思い出せる限り1年以上安心して過ごしている感はないし、常に危機感というか、現状に対する焦りがある、それを無くせば別の見え方ができるんじゃないかなーと思う

でもまあ、焦りの感覚が無くなったら自分何にもしなくなりそうだし、どうなんだろう。よくわかんないや。

日記: Pixel 3が届いた / semantic-ui-react を触っている

Pixel 3, 発表当日に予約して、今日届いた!!!!やったね!!!

操作感とかは他に詳しくレポートしてる人がたくさんいるから特に言わない。
下の常時表示されるボタンがPieになったタイミングで大きく変わったけど、1時間ぐらいで慣れました。

肝心のカメラは暫く使う機会がないです。再来週ぐらいに横浜に行くからその時に風景を撮ってみようかなー?

store.google.com

同封されているEarbudsは思ったより音が綺麗だった。長いこと付けてるとちょっと耳が痛くなったのと、有線だからあんまり使わないと思うけど。


Reactの学習を続けているんですが、本でも使われていたsemantic-ui-reactをいじって遊んでいます。
cssを読み込むのを忘れていて(読み込めっていうのはUsageに書いてある)数時間溶かしたので日曜日はかなり凹んでましたが、今は元気です
introduction見てすぐコンポーネントを見始めたのが良くなかった。ドキュメント読もう。。

ある程度自分でちゃんと画面を考えて、なんか作ってブログを書きたい。今週中かな

Microservices Meetup vol.9 (FiNC App & Frontend)に参加した!ときのメモとか感想レポート

microservices-meetup.connpass.com

FiNC Technologies社が主催するMicroservices Meetup の9回目に行ってきた、ときに学んだこととか、話したこととか、わからなかったことのメモ。
間違った点とかあったら優しくマサカリを投げてくれると嬉しい。

(関係者のツイートを無許可で埋め込んでいます。駄目であればお伝えください。消します)

自分の立ち位置

主にバックエンドエンジニアをやっている人。
Microserviceはちょっとだけ。(?)
最近フロントエンド界隈のことに興味を持ってきてReactの勉強を始めたけどまだ全体像を理解できていなくて苦しんでいる。
最近はエンジニア組織全体での開発効率の向上、コミュニケーション、長期的な開発部隊の経営、みたいなことを一エンジニアとして考えていることが多い。

各発表についてのメモ、と思ったこと

ウェルカムトーク「マイクロサービスとクライアント: 理想と現実の狭間で」

主催の @qsona sanのウェルカムトーク
Meetupの主題である「マイクロサービス」そのものの利点と注意点を説明してくださった。
マイクロサービスにすればサービスが全て疎結合になるわけではない という話がなるほど、となった。
「どこで結合させるか?」「どこで動作を確認するか?(責任の位置)」ということを考えて作っていく必要がある。
で、その結合させる点がフロントエンドで、ユーザ体験を作るために複数のマイクロサービスを使う という感じになる。(=ハブ)

後半ではFiNC社で取り組んできた内容についての紹介と、重要な概念であるBFFとMicro Frontendsについての説明。

最後のスライドが好き。

https://speakerdeck.com/qsona/ideal-and-reality-of-microservices-from-the-client-side?slide=21

ウェルカムトークだからのんびり聞くかと思ったらめちゃくちゃ濃い内容でびっくりしてしまった。これだけでも考えさせられるお話で有意義でした

「クライアントサイドから考えるマイクロサービス」

FiNC Technologiesのクライアントアプリ開発者の @neonankiti san のクライアントアプリケーションから見たマイクロサービスについてのお話。

マイクロサービスによってリソースの表現が違っていて、それを統合させることが難しい、というリアルな課題と、それに対する解決策としての腐敗防止層の流れ。
APIガイドラインとかの考え方もとても参考になる。「コンセンサスを取った上で開発する」ことが明示的になり、重要性が増して、安定した開発フローになる。

腐敗防止層については質問したら細かい定義と必要性について答えてくださった。
(👇のツイートだけじゃなくて上下のスレッドを見ていただけると。)

あと、 次の発表者である@takasek sanと一緒に "iOSアプリ設計パターン入門" という本を書いている @ktanaka117 san からも補足をもらった。ありがとう。

次の話。
リソースの表現の差異と似たような話が別レイヤで起こっている件としてiOS/Android間での実装や設計の違いがあるという問題があった。
iOS/Androidはチームが違っていて、かつ使う技術も違うということで分断しやすそう、という印象は確かにある
で、それを定期的なコミュニケーションを取ったり情報共有をすることで解決した という話だった。

最後にはビジネスインパクトを踏まえた組織構造についての説明。
エンジニアだけで固まるのは確かに良くない(と haze も感じている)。ビジネスを考えた上でのべき論だったり組織構造を考えていくことは重要だと感じた。

「マイクロサービスとクライアントとコンテキスト境界」

FiNCでiOS Appを作っている @takasek sanのコンテキスト境界をどこに置くか、というお話。
境界はチーム編成の輪郭に従う という重要な概念をさらっと説明されていた。

その後の話は自分にDDDの理解が無さすぎて正しく理解できなかった。つらい。
(そもそも今回のMeetupのサブタイトルがApp & Frontendなので理解しておけという自戒)

DDDをはじめとした設計手法について理解がかなり薄くて、結構最近の悩みだったりする。
と思ってたらslackでdanboさんに本を勧められたので買って読んでみることにする。みなさんもぜひ(?)

f:id:hazeblog:20181031112028p:plain:w600

peaks.cc

実践、BFF ~ BFFはFiNCのアプリで何を解決したのか ~

FiNCでAndroid Appを作っている @izmeal2000 san のBFFに重きを置いたお話。
BFFの説明がめちゃくちゃわかりやすいので読んでみてください。

FiNCでBFFを入れたことによる恩恵は3つあって、
- 通信量を減らすことによるパフォーマンスの向上
- 集約ロジックをBFFに集中させることで、クライアントが異なっても挙動を安定させられた
- BFF側にロジックを一部移譲することで、Appの申請をせずに挙動を変更させられるようになった
というもの。

後半はそれの具体的な説明をされていた。と同時に、集約することでのデメリットについてもお話されていた。
完全に一本に集約させると、マイクロサービスが一つ死んだら全てに影響が出てしまったり、一つレスポンスが遅いものがあるとそれに引きずられるといった問題についてはなるほど、となった。

最後にBFFの開発者は誰か、という話について。
一般的に「BFFはクライアント・フロントエンド側の責務で管理するもの」となっているらしく、今はまだアプリ開発者がBFFをガンガンいじれるようになっていないとのこと。
これについては"BFFはその組織にあっているか?"という一つの大きな問題に関わってくる部分。

これを聞いていて、「簡単に言うけどこれ実現するのくそむずくない??」とずっと思っていて、懇親会で聞いたらなんかそうでもない感があって驚いた。
具体的な実装のイメージがついていないんだけど、レイヤをうまく分けて一部レイヤをBFFに渡すことでできるみたいな感じのことを言っていた(わかってない)。

DDD含めて、レイヤの感覚もいまいちちゃんと持ててなくてそれを実装に落とし込めないので追いつきたい。。。

「お礼ポイント投票機能をSPAに実装してMicro Frontendsを実践している話」

FiNCでフロントエンドエンジニアをやっている@nobuhikosawai san の発表。
資料見つからなかった。見つけたら追記予定。

Micro Frontendsに焦点を当てたお話。
そもそもMicro Frontendsとは? から、具体的にどんな技術を使っていてどんな実装なのか?をソースコードレベルで説明してくださっていた。

Reactのeventハンドリングに負債があるらしく、 React Fire というプロジェクトで返済をしようとしている話とかが出てきて、知らないことずくめで面白かった。

github.com

なんか日本語で説明しているQiitaもあった

qiita.com

説明されていたソースコードはあんまりちゃんと読めなかった。つらい。(2回目)

スポンサートーク

finc.com

「健康に気を使っているレベル」の段階に合わせてサービスを考えているっていうのが印象に残っている。

健康...健康になりてえ...

飛び入りLT 「マイクロサービス開発に分散トレーシングを導入してみた」

Wantedlyのインフラエンジニアの @bgpat_ san の飛び入りLT。すごい。
Distributed Tracingをどう実現したか、という話。Open Censusという分散トレーシングの仕組み(規約?みたいなものっぽい)を使って実現しているとのこと。
社内共有ライブラリでシュッと入れられるものがあるの強い。

https://opencensus.io/opencensus.io

Rails + Datadog APMであれば、Distributed Tracingはかなり簡単に導入できる。

docs.datadoghq.com

Wantedlyでは、Application MonitoringはDatadog APMとStackdrive Traceを併用しているとのこと。 併用をするとなると確かにOpen CensusとかOpen Tracingを使う選択肢になる。なるほどなあ

話はずれるけどKubernetesに全サービス乗ってる話も聞きたい。

懇親会

食べ物が一瞬でなくなって笑った
FiNCの方々やWantedlyの方、それ以外にも様々な方と話をして有意義でした。聞いた内容は大体このエントリに散らばって書いている。はず。

iOSの設計周りについて議論コーナーがあって、さらっと聞こうとしたけどさっぱりわからなかったのでBFF周りの話を他の方としてました。にゃーん

ハッシュタグ

twitter.com

話している内容をまとめてくれている人とか、発表資料とか、懇親会で話されていた話を書いてくれている人がたくさんいました。よかった。

概念について、考察 等

腐敗防止層について

  • Microservicesを束ねて、リクエストをクライアントから受け付ける役割のもの。
  • 集約することでリソースの表現を(クライアントから見て)統一することができる、投げるレスポンスの内容の変更をしやすくする、リクエスト数を減らすことでのパフォーマンス改善が実現できる。
  • 腐敗防止層=BFF というわけではない(そういう場合もあるけど)

BFFを誰が運用するのか?及び導入するかの論点

前述した通り、一般的にはBFFはクライアントサイドのエンジニアが開発・運用するものらしい。
FiNCの場合、iOS/Android Engineerがエンジニア全体でも割と多いように見えていて、だからこそ運用できている感がある。
どういうことかというと、組織の状況・人数構成によってBFFが正しく運用されるかどうかが決まる。

バックエンドが多くて、かつサービスが別れまくっていない場合は恐らく自分が質問に書いたようにリソース定義を完璧に作る方が実現可能性は高くて、
BFFを作るコストのほうが高くなる。

で、バックエンドが多くて、サービスが大きく別れている場合はどうするか、となると、BFFとはまた別のバックエンド側で管理するリバースプロキシみたいなものが必要になるような気がしている。
それか、BFFまでにはならないけどAPI Gatewayに集約するとか、諸々。

あとは、ネイティブアプリが存在していないケース。
提供するサービスがWebアプリケーションしかない場合だと、「クライアント間で要求する内容が変わる」みたいなことがなくなる。

BFFを複数個用意する話

冗長化ではなく、役割の違うBFFを用意していく、という話。
ツリー構造っぽい感じになる。現時点でこれやっている事例ってどれぐらいあるんだろう?

コンウェイの法則・組織構造

「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」 (原文: "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.")

引用: メルヴィン・コンウェイ - Wikipedia

職能横断 / 事業部型 の組織構造かによって採用する技術も、開発する体制も、必要な人員も変わってくる。
前述している「BFFを導入するか?」の話にも被るんだけど、組織ごとによって必要となる様々なリソースは変わるので、他社事例とかは参考にすべきだけど、それをそのまんま社内に導入するのは待ったをかけたほうが良い、という話。

FiNCの場合はこういう前提だった。弊社はどうだろう?を必ず考える必要がある。

他 参考資料

公式の参加レポート。

クライアントサイドとマイクロサービスの難しい関係 — Microservices Meetup Vol.9 (FiNC App & Frontend) 登壇内容レポート #microserv

ウェルカムトークでも紹介されていた、Microservices Meetup の2回前( vol.7 Micro Frontends)に関するエントリ。

medium.com

と、そこで行われたパネルディスカッションのレポート。

medium.com

あと何人か既にレポートを書いているっぽいので、ハッシュタグをさらって見てみると良いかもしれません。
※この記事は @haze_it_ac の色眼鏡を通して書かれています。

おわりに

microservices-meetup.connpass.com

ウェルカムトークから発表、懇親会まで全てが濃い時間でとても楽しかったです。
全ての内容を理解して吸収できなかったことがとても悔しいので、これから概念とか用語とかを理解していきたい。勿論実装も。

自分たちでも知見を作って共有できる側になりたいので、がんばっていきたいぞい

主催・運営の方々、発表者や話してくださった方々、ありがとうございました!

create-react-app(version=react-scripts-ts) で生成されたコードを読む

github.com

Microsoftが create-react-app のTypeScriptバージョンを提供しているらしく、それを使って React + TypeScript でアプリケーションを作る練習をしようとした。
んだけど、どういう手順で作って行くのかがいまいちよくわからなかったので、とりあえず生成された中身を読んでみることした。

github.com

create-react-app の本体リポジトリにもTypeScriptのサポートが入るみたいで試してみたけど、上手く動かなかったのでやめた。
(型の確認まではできるようになったけど、 ソースコード.js のままで、全部書き換えないといけなかった。それはそれでTypeScriptの勉強になりそうだからそのうちやりたい。)

レベル感

自分は、Node.js を使った外のAPIを叩いたりJSONを投げるアプリケーションは作ったことはあるけど、フロントエンドに関しての実装はしたことがない状態。
jQueryも知らないし、画面描画に関わるJavaScriptのコードはほぼ全く読めないと言ってもいい感じ。

Reactは2回本の写経をしたけど、あんまりちゃんと理解していない。コンポーネントのpropsとstateの使い分けは本に書いてあったから雰囲気でわかる、と思っていたけど完全に忘れた。
TypeScriptは名前しか知らなくて、型付きのJavaScriptコンパイルしてくれる便利なやつ という認識。
本の写経したとき雰囲気だけはわかったけど、細かい仕様はわかってない。

ソースコードを読む前にやったこと

前提となるES2015〜のJavaScriptの文法を確認する

初めてのJavaScript 第3版 ―ES2015以降の最新ウェブ開発 を軽く読む。 jQueryの話、基本的なデータ構造周りの話は飛ばして、ちゃんと理解しているか怪しい部分だけさらった。
具体的には、 ジェネレータ( function * )、class、prototype周り。

TypeScriptの基本的な部分を理解する

Qiitaを読んだりした。
Typeのことがよくわからなかったが、Qiita: TypeScriptのInterfaceとType aliasの比較 で雰囲気は理解したと思う。

init-appをつくる

$ npx create-react-app init-app --scripts-version=react-scripts-ts
$ cd init-app
$ npm run eject

github.com

これができる。
npm run eject は、create-react-app側で良い感じにまとめられていたパッケージを分解する処理を走らせる。

eject前は、 package.jsonのscripts欄は

  "scripts": {
    "start": "react-scripts-ts start",
    "build": "react-scripts-ts build",
    "test": "react-scripts-ts test --env=jsdom",
    "eject": "react-scripts-ts eject"
  },

こうなっていて、ejectをすると

  "scripts": {
    "start": "node scripts/start.js",
    "build": "node scripts/build.js",
    "test": "node scripts/test.js --env=jsdom"
  },

こうなる。
react-scripts-ts という便利コマンドが作られていて、それを解除するという感じ。

ちなみに、 start を実行をしたときに走る scripts/start.js は以下。

create-react-app-ts-init/start.js at master · haze-it/create-react-app-ts-init · GitHub

初期状態では混乱しないようにパッケージングされていて見えなくなっている、ということ。
(そもそもejectをする前は /scripts ディレクトリが存在しない)

中身

読んでいきましょう。

起動 - scripts/start.js

起動コマンドは npm run start か、 yarn start

f:id:hazeblog:20181029210648p:plain:w300

さっきも書いた通り、 start を実行すると、 scripts/start.js が実行される。
create-react-app-ts-init/start.js at master · haze-it/create-react-app-ts-init · GitHub

まず、14行目で config/env.js が読み込まれている。

f:id:hazeblog:20181029211757p:plain:w400

config/env.js はこれ。

create-react-app-ts-init/env.js at master · haze-it/create-react-app-ts-init · GitHub

env.js の中では、キャッシュを消したり、 NODE_ENV が存在するか確認したり、 .dotenv ファイルを読み込んだり、 NODE_PATH を設定したりしている。

その後は、色んなモジュールを読み込んで

f:id:hazeblog:20181029213333p:plain:w500

起動するためのホスト(通常は 0.0.0.0 )とポート(通常は 3000 )を指定している。
(この下に書かれているものは Cloud9内で起動した場合に実行される内容なので飛ばす)

f:id:hazeblog:20181029213824p:plain:w400

そして、63行目の choosePort でポートを取得する。
f:id:hazeblog:20181029214159p:plain:w300

この choosePort メソッドは react-dev-utils/WebpackDevServerUtils から持ってきているもので、「指定のポートが空いていたら獲得し、空いていなかったらユーザに次のポートを取りに行くかを確認する」機能を持つ。
試しに3000番ポートを埋めた(別Appを起動させた)状態で npm run start をすると、以下のようなエラーメッセージが出て、 y とかエンターを押すと 3001番ポートを取りに行ってくれる。

f:id:hazeblog:20181029214700p:plain:w400

npm - react-dev-utils: WebpackDevServerUtils
便利。

choosePort が成功したら、HTTP or HTTPS、Appの名前を確認して、URLを設定して、

f:id:hazeblog:20181029215103p:plain:w400

webpackで各モジュールをバンドル(複数のファイルをまとめる)して、

f:id:hazeblog:20181029215353p:plain:w500

proxyの設定を package.json から取ってきて

f:id:hazeblog:20181029215633p:plain:w500

起動!!+ブラウザを開きます。

f:id:hazeblog:20181029215754p:plain:w600

その下には Ctrl+C 押したりした時に終了する処理が書かれている。

f:id:hazeblog:20181029220650p:plain:w500

というのが start.js の処理。この辺を全部勝手に用意してくれる create-react-app便利だなーという感じ。

src/index.tsx

ここからReact。

最初に開かれるアプリケーションは src/index.tsx
これは paths.jsappIndexJs という定数部分に記述されていて、 webpack.config.[env].jsentry でそれを最初に実行するように設定されている。
(webpackの仕様)

path.js
f:id:hazeblog:20181029223008p:plain:w400

webpack.config.dev.js
f:id:hazeblog:20181029223132p:plain:w600

src/index.tsx
create-react-app-ts-init/index.tsx at master · haze-it/create-react-app-ts-init · GitHub

短め。

react , react-dom モジュールをimportして、
./App.tsx , ./index.css , ./registerServiceWorker.tsx を取ってくる。

App が実際のアプリケーションで、 index.css は普通のライブラリで、 registerServiceWorker.tsx は名の通りServiceWorkerの部分。

行なっているメインの処理はこれだけ。
ReactのDOMに App.tsx の中身 と index.html 内にある <div id="root"></div> を投げている。 f:id:hazeblog:20181029225225p:plain:w500

div rootHTMLElement にキャストされている。 HTMLElement は任意のHTML要素を表すものらしい。

HTMLElement - Web API インターフェイス | MDN

document.getElementById() は普通のJSのやつ。

Document.getElementById() - Web API インターフェイス | MDN

そのあとにServiceWorkerを走らせているけど、これは後述。

App.tsx

create-react-app-ts-init/App.tsx at master · haze-it/create-react-app-ts-init · GitHub

メインの処理部分。
react モジュールをimportして、cssとlogoを取る。

f:id:hazeblog:20181029231203p:plain:w600

Reactはコンポーネントという単位でUIを分けていて、その定義は、 React.Component を継承することで実現する。( extends React.Component

初期状態だとコンポーネントは一つしかないので、この App コンポーネントが画面全てを描画している。

f:id:hazeblog:20181029232224p:plain:w500

一般的なReactアプリケーションだと、entryにルーティング用のtsxをかませて、それでコンポーネントを出し分けたりするっぽい。

training-react-app/webpack.config.js at master · haze-it/training-react-app · GitHub

training-react-app/Routes.tsx at master · haze-it/training-react-app · GitHub

くるくる回るロゴは普通にCSS animationだった。(なんかのReactの機能を使ってると思ったら全然そんなことなかった)

f:id:hazeblog:20181029233132p:plain:w500

メイン処理は以上。

registerServiceWorker.ts

create-react-app-ts-init/registerServiceWorker.ts at master · haze-it/create-react-app-ts-init · GitHub

Service Workerってなんだ。雰囲気しか知らない。

developers.google.com

ブラウザ上の描画とは別に、スクリプトが実行できる環境が用意されていて、そこでプッシュ通知の処理をしたり、バックで処理走らせたりができるもの。
Webページ側の処理とは全く別のものなので、バックグラウンドで同期処理を走らせたりしても描画に影響はないみたい。便利そう。

registerServiceWorker.ts を読んでいく。

前半の事前処理で多用されている window.location について 。表示しているURLの情報とかを取ってこれるっぽい。
Window.location - Web API インターフェイス | MDN

envがproductionじゃないと登録処理がそもそも行われないようになっている。
f:id:hazeblog:20181029235801p:plain:w600

後ろの 'serviceWorker' in navigator は ブラウザが対応しているかを確認する処理らしい。
Navigator.serviceWorker - Web API インターフェイス | MDN

これは、動くworkerが別ドメインのものでないかを確認している。セキュリティ対策かな?
CDNを使ったりする場合はそのURLを入れたりする処理も必要になるっぽい。
f:id:hazeblog:20181030001128p:plain:w600

で、メインの登録処理と実行処理。
f:id:hazeblog:20181030001509p:plain:w700

swURL は、 実行するスクリプトのURLを入れている。
初期状態だとローカルホストでしか動かないようになっていて、 checkValidServiceWorker(swUrl: string) で、別のアプリのservice workerが登録されていないかを確認している。
checkValidServiceWorker は下の方で定義されている)

navigator.serviceWorker.ready.then(() => { .... } でserviceworkerを登録する。
直接DOMを編集できないので、 postMessage という機能を使って送り込む処理が必要らしい。その辺は別の記事を読んでください。

App.test.tsx

create-react-app-ts-init/App.test.tsx at master · haze-it/create-react-app-ts-init · GitHub

create-react-app-ts-init/README.md at master · haze-it/create-react-app-ts-init · GitHub

Testing-Components というものがあるらしい。
テストは追々で。


というわけで、一部雑に飛ばしたけど、メインの機能周りはこれでおしまい。
package.jsonとかtsconfigとか、configのpolyfill(ブラウザで対応していない機能を独自で実装するやつ)とかjest(テスト)辺りは後々深く見ていこうと思う。

とりあえず、次はイメージする画面を作る練習をいくつかする予定。

日記: NETATMO ウェザーステーションを買った

ここ最近寒くて起きるのと、そろそろ乾燥し始めて体調を崩しやすくなる時期ということもあって、部屋の状態把握ができると良いなと思っていた。

最初はCO2センサとか温度センサとかを買ってIoT的なことをしようかと思ったけど、思いの外CO2センサが高かったのと、調べてる途中でめんどくさくなってきたので既製品で良いか、となり、前から気になってはいたNETATMOの製品を購入。

説明書は海外製品によくある(?)、説明文がなくて図が順番に乗っている形式。
これがめちゃ分かりやすくて、最高の体験だったのでみんなそこだけは体験してほしい。

唯一、子機側の光る場所が地面に置くほうでそこだけびっくりしたけど、特に支障はなし。

親機はリビングの作業スペースに、子機は寝室に置いた。


セットアップが終わると、PCサイトでログインすれば部屋の状況が見れるようになる。

f:id:hazeblog:20181027084401j:plain

SPAのダッシュボード。
中心の表示内容をコントロールできて便利。レスポンスも早めで普通に体験として良い。

Angularだった。

アプリもiOS/Androidで提供されていて、ダッシュボード同様かなり見やすくて良い画面だと思う。


ダッシュボードとアプリが良い感じでもうこれでいいや〜感はあるんだけど、APISDKが提供されている。

dev.netatmo.com

適当にポーリングして、温度が一定以上に下がったら指定の処理を走らせたり、ウィジェットを作ってホーム画面に表示させたりができる。
なんか面白い使い方を考えたい。

とりあえずエアコンと連携させたいのでNeture Remoが欲しい。あれもあれでそこそこの値段するんだよな。