taiki-t's diary

きぎょうにっき, React Native, Rails そして雑多な記録: The world is waiting for you to give it a meaning.

React Native のTouchableなんとか使うときの注意

TouchableWithoutFeedbackとか使うとき、 とりあえず内部の要素はTextだろうがImageだろうがViewでラップしておくのが無難。 余計なハマりポイントを回避できる。

バージョン: 0.44.0

試訳: combineReducers

Redux documentsの「Using combineReducers」の最初だけざっと試訳してみた。推敲してないので間違ってたら申し訳ない。とはいえ割と合ってると思う。まあやってみたのを手元に置いておくだけなのも勿体無いので置いておく感じ。改善は自由に。


combineReducersを利用する

中心となる概念

Reduxアプリケーションにおける最も一般的なstateの形式は、素朴なJavaScriptオブジェクト(plain JavaScript object)がトップレベルキーのそれぞれにドメイン固有データの「一部分」を保持する形式です。 同じように、この形式のstateに対するreducerのロジックを書くアプローチとして最も一般的なのは、それに対する「部分reducer」関数を書く方法です。具体的には、reducerそれぞれが同じ(state, action)シグネチャを持ち、それぞれがそのreducerに固有のstateの部分に対するすべての更新を管理する責任を負うように書きます。複数の部分reducerが同じアクションに応答することもありえます。その場合それぞれが独立に、必要に応じて自身の担当するstateの部分を更新し、そして更新された部分は新しいstateオブジェクトに合体(combine)されます。

このパターンはとても一般的なので、この振る舞い実装するためにReduxはcombineReducerユーティリティを用意しています。これはhigher-order reducerの一例です。これは、部分reducer関数が詰められたオブジェクトをとり、新たなreducer関数を返すものです。


原文

Using combineReducers

Core Concepts

The most common state shape for a Redux app is a plain Javascript object containing “slices” of domain-specific data at each top-level key. Similarly, the most common approach to writing reducer logic for that state shape is to have “slice reducer” functions, each with the same (state, action) signature, and each responsible for managing all updates to that specific slice of state. Multiple slice reducers can respond to the same action, independently update their own slice as needed, and the updated slices are combined into the new state object.

Because this pattern is so common, Redux provides the combineReducers utility to implement that behavior. It is an example of a higher-order reducer, which takes an object full of slice reducer functions, and returns a new reducer function.

リンク

Using combineReducers · Redux

Lylicaというサービスをリリースした。

Lylica (りりか) というサービスをリリースした。iOSアプリで。

f:id:taiki-t:20170621160719p:plain:w500

Lylica - 街のおすすめが分かるSNSを App Store で

「世界をもっとダイナミックにしたい」

そう思って作ってきた。きっかけは、昨年(2016)に翻訳書1を出版したことに遡る。

昼間は会社、夜は翻訳、週末も翻訳。そういう生活を1年半近く過ごしてきて実感したのは、 息抜きにどこかに出かけたいけど調べる時間もない、ということだった。

何かをやるには調べる必要があって、調べるにはスキルと知識2が必要で、そして時間も必要で。 僕はその余裕がなかったので、結局いつも決まったカフェにいくルーティーンで日常は終わった。

けれど世の中というのは自分の知らないところでも回っていて。 あの時近くでこれがやってたと後から知ったり、偶然通りがかった時にお祭りをやってることを発見したりだとか、 そういうことを多々経験した。その時に思ったことはいつも

「近所のことぐらいすぐ手元でわかったらいいのに」

だった。

「世界をダイナミックにする。」その答えの一つは、そのような人の人生により多くの選択肢をその場で提供することにある。 そうすれば、調べる時間がなくても、調べる言葉が思いつかなくても、その人はもっと色々なものに参加できるようになるかもしれない。 つまり、その人の人生はもっと豊かに、ダイナミックになるかもしれない。

そういうことを、実現したい。

f:id:taiki-t:20170621163109j:plain:w620

偶然通りかかったお祭りにて -- 2016/08/20 18:47

Lylicaでできることは今のところ主に次の2つとなっている。

  • その場のできごとを写真にとってシェアする
  • 付近の投稿を閲覧する3

世界をダイナミックにする、それだけだったら別の方法もあると思う。 それをなぜこういう機能にしたのかというと、他に実現したいことが2つあるからだ。

  • 「人と場所、人とできごとを繋げる」
  • 「人のその場所での営みを残す」

世界をダイナミックにすると同時に、これらのことも実現したい。

僕の両親は自営業だった。いわゆる個人商店。幼い時からずっと見てきた光景の一つが、人集めの苦労だ。 僕は、そのように個人で物事をやる人たちの手元に助けとなるツールを提供したい。4 低コストで、かつ簡単に地域の人たちに情報を届けられるツールを。

人と場所、人とできごとを繋げれることができれば、世界をダイナミックにできると同時にそのツールを提供できる。

そして、

実家は福島にある。2011年、震災を経験した。いろんなことが変わった。景色、生活、習慣。 それは失われたと言っていいのか、新しいものを得たと言えばいいのかわからないけど、僕が経験したのは喪失感だった。 それは今でも変わらない。

無くしたものを数えてもしょうがないんだけど、でもそれはこれからに向けて対策を取らないこととは異なる。

人がその土地で営んだ記憶、記録を残したいと思ったのはそれからだ5Googleの使命が世界中の情報を整理し、世界中の人々がアクセスできて使えるようにすることならば、 Lylicaの使命の一つは、人々がその土地で営んだ記録を残し、整理しアクセスできるようにすることだろう。

そうすれば、僕が失ったものの半分は失われずに済むような気がしている。

そういうわけで、Lylicaは簡素ながらも、

  • 「世界をもっとダイナミックにする」
  • 「人と場所、人とできごとを繋げる」
  • 「人のその場所での営みを残す」

の3つの目標を全て実現できる可能性を秘めたプロダクトとして生まれた。 この3つが実現できるかはこれからの運用にかかっている。機能の追加は、その3つの目標の元に行われていく6

なにか思うところがあった人はなんでも連絡をしてもらえると嬉しい。TwitterのDMにでも。この記事は特にそんな人のために書いている。

そして何より、インストールして使って、フィードバックをいただけたらと思う。

ダウンロードはこちららから: Lylica - 街のおすすめが分かるSNSを App Store で

始まったばかりのサービスですが、何卒よろしくお願いします。

f:id:taiki-t:20170621173917j:plain:w620

少し曇りだったけど変わらずきれいな三春の滝桜 -- 2017/04/22 05:59


  1. オブジェクト指向設計実践ガイド 「日本のITエンジニアの生産性をあげる」という個人プロジェクトの一環で取り組んだ。

  2. 例えば乗馬ができる土地に立ち寄ったとして、そこで乗馬ができることを知らないのにどうして「乗馬体験 地名」というような検索ワードをGoogleなりに打ち込むことができるのだろうか。何かを知るためにはそもそも知っていなければならないというパラドックスがある。知識ゼロでその土地に降り立ったとしても人は自分の選択肢を知ることができなければならない。

  3. こういう機能、地域SNSっぽいけどコミュニティ構築をしようとは思っていない。個人的には、向かい合って手を取り合うような属し方は不得意。そういう文脈で言えば実現したいのは「街の映画館で映画を見てて、ふと笑ったら隣の人も同じところで笑ってた」感。そういう空気感がある地域は、いざという時にも強そう。

  4. toBに関しては、以前のチームであるMisocaで取り組んできた。個人で物事を行う人たちの時間を節約するということは、僕のような子供が両親と過ごす時間が増えるということだ。それはよいことだと思っている。

  5. 被災地においては、歩いて行けるぐらいの距離の違いでも物資配給の列の長さが全く異なるという光景を目にした。そういうのも解決できたらと思う。

  6. 間近の目標としては、2020年には誰もが1ブロック先の情報を気軽に把握できるようにしていたい。このままじゃそうなっていない未来がきてしまう。

メモ:React Native で e2eテストできそうな detox

https://github.com/wix/detox

これ使えそうと思ったけど、Permission用Alert周りの処理で詰んだ。 工夫すればできそうだけどまた後ほどtryする。 導入自体はすごく簡単だった。

このIssueがcloseする頃にはそこらへんいい感じになってるのではと期待:

github.com

react-devtoolsをReact Nativeで使う

React Nativeで開発でのデバッグにはNuclideを使っていたけど、react-devtoolsも使える。

インストール方

グローバルにインストールする場合

  • npm install -g react-devtools
  • これでreact-devtoolsとterminalでやれば走る。

プロジェクトにインストールする場合

yarn

  • yarn add --dev react-devtools
  • yarn react-devtoolsとterminalで打てば走る(プロジェクトフォルダにて)

npm

  • npm install --save-dev react-devtools
  • "react-devtools": "react-devtools"package.jsonscriptsのとこに書く
  • npm run react-devtoolsとterminalで打てば走る(プロジェクトフォルダにて)

使い方

  • SimulatorでCommand + Dして出てくるメニューから Show Inspectorを選択
  • 要素をクリックすると、devtoolsの方で連動して表示してくれる。

まあここら辺はNuclideとあまり変わらない。 ただNuclideというかAtomが重いのでdevtoolsの方が気軽に使えそうな気がしている。

参考

github.com blog.expo.io

Mark Zuckerberg's Commencement address at Harvard

www.youtube.com

What I thought listening to this is: “It’s not the world that gives you the meaning, the world is waiting for you to give it the meaning.”

GraphQL Mutation

Relay使ってての話なんだけど

  • Mutationはできる限り単一責任にした方が、のちのユースケース変更時にコスト低そう
  • リソースに対する状態変更は、Mutation名を動詞にしてidだけ送るとクライアントとサーバー側を疎結合にできて良さそう

UpdatePostStateMutationとかで変数に{ id, status: 'visible' }とかやるんじゃなくて HidePostMutation, ShowPostMutationとか作ってidだけ送る。status: 'visible' とかの状態名ってどうしてもサーバー側の知識が漏れがちだから、idだけ渡す方が変更に強そう。