2017-05-22

メモ: React Navigation を使い始める時に確認すると良さそうなこと (v1.0.0-beta.10時点)

React Native

Release v1.0.0-beta.10 · react-community/react-navigation · GitHub

React Navigation V1.0.0-beta.10が出た。そう、React Navigationはまだbetaが取れてない。使い始める前に現状どんな問題があるか確認しておくと時間を節約できると思う。どこを確認すればなんとなく検討できるかというと、GitHubレポジトリに上がっている次のIssue。

github.com

v1.0.0-stableを出すにはこれらを全て解決しようというコミュニティの意向が反映されている。このチェックボックスがついていないものは機能として存在しないので気をつけると良さげ。たとえば2017/5/22時点で Screen lifecycle hooks は実装されていない。つまりReduxとかを併用していればごにょごにょできるかもしれないが、React Navigation単体ではタブをユーザーがタップした時点で何かアクションを実行するというようなことはできない。*1

あとはまあ一般的なことだけど出てるIssueはざっと眺めた方が良い感。

他、一応v2へのロードマップもちょこっと出てる

v2 Roadmap · Issue #1263 · react-community/react-navigation · GitHub

Exampleをざっと動かしてみるのも良いかもしれない。

https://github.com/react-community/react-navigation/tree/master/examples

感想戦:

相変わらず全体的な印象の話になってしまうけど、機能としては存在しても細かいところまでは詰められていないことも多々ある。機能はあるけど微妙な挙動をすることもあるので、そういうものにぶつかった時は割り切りあるいは自分で直す覚悟が求められる。

たとえば:

タブ内で画面遷移すると、タブの表示(画像、ラベル)も切り替えられてしまうので自分で対策する必要がある
画面遷移によっては、戻ったあとにその戻る前のタイトルが一瞬表示される

などなど。

こういうことばっかり書くと使うのやめようってなるかもしれないけど、でも使ってほしい。

https://www.facebook.com/groups/react.native.community/permalink/988488134620098/

React Native Community上ではnavigation libraryの中ではReact Navigationが優勢な模様

*1:回避策としてHOCでProxyScreenを作ってそこでアクションを実行するとか、リロードが必要なところは全部モーダルで出すとかすればできないこともない。けど筋肉が必要。

2017-05-22

Relay Modern rewriteについてのメモ

Relay

We still had that long backlog of ideas, but we knew that we were adding to the tail of the queue faster than we were shifting from the head of it. It was a scary prospect, but we came to the conclusion that it was time to burn it all down and rewrite the thing from scratch. We knew we had to unlock performance wins that would require drastic changes, and rewriting was the only way we were going to be able to do it before old age, senility and burn-out took us out of the game. A risky move — big rewrites are often warned against for a reason — but we felt like we had to take the gamble. In doing the rewrite, we knew that the risk of failure (in typical “Second System Syndrome” fashion) was real, but inaction would have led to certain failure.

Building Relay Modern · wincent.com

すげぇ

Relay Modernはかなりの書き直しだったそうだ。システムの書き直しにチャレンジしたことがある身としては、上記の段落の葛藤がそのまますぎてグッときた。成功してよかったなぁ。

2017-05-16

運がいいとか悪いとか

雑記

よく運気をあげるとかいう話を聞く。運をよくすれば物事がうまくいくとか。ただそれだけを聞くと眉唾というか実態のない怪しいものを崇めるような雰囲気が漂う。

運気をあげるために日頃の行いをよくしなさい、的な。

これ、運気っていうとよくわからないけど、「人に声をかけてもらえるかどうか」ってことに換言すると、そうだなと思う。

良い話を回してもらえるかどうかというのは、結構その人の人柄にかかっていると思う。というか、良い話をわざわざ嫌な奴に話す人はそういないだろう。

で、その人柄ってのは日頃の行いの積み重ねだ。

そういう意味で、運をよくするために行動を改めるというのは理にかなっていると思う。どこで誰が何を見ているかはわからない。人の悪口やポイ捨てなどがたまたま見られていて「あ、こいつに話すのはやだな」って思われたら運気が下がる。つまり人に良い話を持ってきてもらえなくなる。 *1

運も実力のうちとはそういうことだ。*2

けっして壺を買うとかそういうことじゃない。短絡的に壺買えば運気が上がるなんてのは絶対に信じてはいけない。*3

*1:かのリチャード・ブランソンが、自殺相談だかの電話に親身に対応していたおかげで、忘れた頃に有益な情報を教えてもらって助かったとかいうエピソードがあった気がする (アフィリンク: ヴァージン―僕は世界を変えていく) 。それを幸運と呼ぶならば、そういう幸運に恵まれるかは自分次第だ。途方に暮れた時に人に手を差し伸べてもらえるかとか、そういうもそう。

*2:わかっていはいるけれどそういう意味で僕は実力がない。不親切で無礼だ。結構損してきたと思う。でもこういう内容をかけるぐらいには声をかけてもらってきた。ありがたい。

*3:壺買って運気が上がる人は一部いるだろう。つまり「こんな壺を持ってるということは、信用できる」と思考するような、力のある人が周りにいるかどうかだ。あいにく僕の周りには骨董好きもいないし、そんな壺を選ぶ審美眼も自分は持ち合わせていない。壺がメタファーだとすればもう少し範囲は広がる。適当な美術品その他に置き換えてもいい。例えばいい美術品を持っていれば、レオナルド・ディカプリオに自宅に招待してもらえるなんて「ラッキー」も起こるかもしれないね。この場合のラッキーとは、自分の想定外、あるいはコントロール外にある「自分にとっての良いこと」が自分に降りかかって来ることかな。そういうものが思いがけず自分の手元に飛び込んできたら、嬉しくて自然と自分はついてると思えるものね。

2017-05-15

Sketch3 グラデーションでぼかす

Sketch3

かなり前にこんな記事を書いた

taiki-t.hatenablog.com

グラデーションでぼかす方法はまた今度紹介するなどと言いつつずっと書いてなかったので手軽に手順だけまとめておこうと思う。

四角を二つ重ねてかく。一つ書いて⌘ + Dすれば楽だろうか。
その二つの四角を選択してMaskを選択
上のメニュー Layer からMask Mode > Alpha Maskを選択
上に重なる四角には、横のメニューからBackground Blurを選択
下に重なる四角には、横のメニューからFillを選択し塗りつぶす
1. このとき、上は透明、下は白とかでグラデーションで塗りつぶす
2. これでグラデーションのかかる範囲を調整
適宜Background BlurのAmountを調整

2017-05-05

西日暮里.rb 36回目「Electronではじめるアプリ開発」発売記念 LT 大会!」の記録

React Native 雑記日記感想文 Relay

nishinipporirb.doorkeeper.jp

参加してきた。というか主催者の一人w

今回はオーガナイザーの一人であるじょうさん (@joe_re) が本↓を執筆したので記念LT会をした。

gihyo.jp

テーマは自由。けれど本がElectronということもあり、かなーりfrontよりのLT会だった

今日の西日暮里.rb、JavaScriptコミュニティにいるような感覚だ #ninirb
— じょう (@joe_re) 2017年4月24日

まぁRubyistsといえど技術好きの集まりには違いないし、これからもどんどん楽しそうなことやっていきたい。

やったこと

LT大会というとばーっと話しておわりだけど、今回は（も）フィードバック込みでやった。 Lightning Talk & Lightning Feedback（LTLF）という形式で、以前から何度か試している。これはオーガナイザーの一人であるまつしまさん（@mtsmfm）の発案で始めた試みで、場がかなり濃くなるので良い。楽しい。

具体的には、

LT中に聴衆がそれぞれ思ったことや疑問などを付箋に書く
LTが終わったら壁に集まって順番に付箋を貼りつつ
その内容について話す、LT発表者が答える

という形式。発表者の一方通行で終わらないので、普通にやるよりは学びが多いと思う。人数が多い時はどうしたらいいんだろう、って問題もあるけど、そん時はTrelloなりにバーっと書いて非同期でフィードバックするというのが良いのだろうか。

発表内容

基調講演はもちろんじょうさんだった

あとはスライド探しきれていないけれど、ざっと内容を書くと:

ElectronでOpalの話 @mtsmfm
でかいPRとどう向き合うかの話 @HKDnet
fastlaneのmatchの話 @color_box
Electronで動かす音声認識、音声合成の話 @iidaapp
React Native + Relay + Redux + Railsでアプリ作った話 @taiki__t

という感じだった。一文でまとめたので雑。Opalのすごいコードみたというのと、fastlaneのmatchがスタックしてるとき裏でパスワードをきいているという話がとても印象に残っている。

自分の発表のスライドはこれ:

近々リリースするアプリの技術的側面について話した。デプロイゲートにてテスト版配布しているので、(iOSのみ): https://dply.me/435uls 気軽に試してフィードバックをもらえると嬉しい。

最後に

西日暮里.rbではまた6月にもLT大会を予定しているので、ぜひご参加ください。

西日暮里.rb | Doorkeeper

上記ページより「コミュニティに参加」をすると次回開催のお知らせがくると思います。

2017-04-23

Relay Modernへの移行検討をした

Relay

結論: もう少しドキュメントとサンプルが増えてからにしよう（rcが外れる頃かな？）

追記: 2017/08/21: 移行しました: Relay Modernに移行した - taiki-t's diary

背景

現在アプリを作っていて、フロント側の構成はReact Native + Relay + Reduxという感じだ。

（Relay Modern以前のバージョンはModernの登場によりRelay Classicと呼ばれるようになったのでこの記事でも以後Relay Classicと呼ぶ。)

ネットワークを介するデータについてRelay Classicは素晴らしく機能的だったが、ネットワークを介さないデータの管理には向いていない。というかRelay Classic標準ではできない。

そこで出てくる問題は、コンポーネントを跨いだアプリケーショングローバルのステート管理だ。（コンポーネント単位のローカルステートであればそのままReactのstate, setStateを使って管理すれば良い）

つまりログインステータスなどをアプリケーション全体で一貫して管理するにはそこの層を導入する必要がある。

ReduxもしくはFluxがそこで登場するわけだが、自分の場合Reduxを選んだ。FacebookはFluxを使ってる/たとの話だ*1。

しかしやはりそのためにReduxなりFluxを導入するのは欲する結果と得る複雑性の観点から合理的とは言い難く(個人の感想)、issueなどでもローカルステートの管理をしたいとの要望などは上がっていた。

Relay Modernについて

Relay Modernでの改善については New in Relay Modern - Relay Docs に詳しいので再掲するようなことはしないが、今回Client Schema Extensionsなるものが入る。これはまさに上述の問題を解決するものだ。公式の説明にもそのように記述されている。

This should be able to replace some use cases that previously required a Flux/Redux store on the side.
– https://facebook.github.io/relay/docs/new-in-relay-modern.html#client-schema-extensions より一部抜粋

そのほかに導入された改善として目につくのは、

の2つだ。前者はRelay Classicに慣れ親しんだものにとっては移行コストであって、新規の人への恩恵が大きい。学習コストが下がってるはずだ。後者については、自分のアプリでもそう遠くないうちに導入したい機能だと思っている。

Relay Modernへの移行について

※ ほとんど個人的な話

まぁ自分の場合いまのアプリケーションで差し迫って必要なのはローカルステート問題を解決する機能なので、そこがアップデートへのモチベーションとなる。ところが、そのClient Schema Extensionsについて具体的な実装に触れたドキュメントは2017/04/23現在、存在しない。似たようなドキュメント難民の声がIssueに上がっていた。

github.com

提示されたリンクからいくらかざっと辿ってみたけれど、@exportというディレクティブを使うんだ、metadatapropsに入るのかな？ということぐらいしかわからなかった。それでも試してみようかと思ったけど、そもそもIssueに答えたFB中の人が

but getting this to work outside the FB environment hasn’t yet happened.
– https://github.com/facebook/relay/issues/1656#issuecomment-296249276

と言っているので冒険にはまだ早いなと思いとどまった。もう少し合理的な努力ができそうになってからトライしよう。そういう訳でまだアップデートしない。

*1:

2015/02/20 もう2年前の情報。2017年現在はどうなってるか知らない:

At Facebook, we have apps built entirely using Flux, entirely using Relay, or with both. One pattern we see emerging is letting Relay manage the bulk of the data flow for an application, but using Flux stores on the side to handle a subset of application state.

https://facebook.github.io/react/blog/2015/02/20/introducing-relay-and-graphql.html#how-does-it-relate-to-flux