DEV Community: Kyoko KADOWAKI

React Native v0.63.0 がリリースされたので変更点をチェックする

Kyoko KADOWAKI — Tue, 14 Jul 2020 08:09:22 +0000

React Native の v0.63.0 が 7/6 にリリースされました。

公式ブログによるアナウンス

大きな変更点は以下となります。

LogBox の導入
Pressable Component の追加
Native Colors の導入
Node 8 系、iOS 9 のサポートを廃止

以下、それぞれの変更点を具体的に見ていきます。

LogBox の導入

これまでの React Native 開発では、エラーや警告メッセージの出力がわかりづらく、そこが開発しづらさにつながっていました。

例えば console.log, console.warn などで出力したメッセージを React Native の devtool 経由でしか確認できないなどの問題がありました。

LogBox はそのような開発者の声を受けて、開発しやすいログメッセージの出力 UI を提供するインタフェースとして新たに開発されたもののようです。

LogBox によって、以下のような変更がもたらされます:

console.xxx で出力されるメッセージの出力
- これまでブラウザの devtool や logcat (Android) などで確認しなければならなかった console.log, console.warn, console.error などの出力を直接アプリケーションから確認できるようになりました。
コードフレームの出力
- エラーや警告にアプリケーション内のログのソースコードを表示するコードフレームが含まれるようになりました。
コンポーネントスタック
- これまで出力されていたコンポーネントスタックがエラーメッセージからは削除され、独自のセクションに配置されるようになりました。これにより、ログメッセージをコンポーネントスタックフレームとそうでないもので切り分けて見ることができるようになります。
スタックフレームの省略
- アプリケーションのコードに関連しない (= React Native のコア部分の) コールスタックのフレームが省略されるようになりました。これにより、React Native 内部のエラー出力を覗くことがなくなり、開発しているアプリケーションのエラー箇所を解りやすく追うことができるようになりました。

Pressable Component の追加

React Native では、押下が可能な UI パーツとして、 Button や TouchableOpacity などのコンポーネントを利用することがデフォルトで推奨されています。

ただ、これらのコンポーネントはデフォルトの UX (ホバー、ブラー、フォーカス)などが既定されており、カスタマイズが難しいという問題がありました。

Pressable は、これらの問題を解決するために新たに提供されるコンポーネントです。

このコンポーネントは、Button や TouchableOpacity よりも抽象的なコンポーネントで、さまざまなインタラクションを検知し、またその状態を保持・取得できるものです。

これによって、押下されているときのスタイル などを独自に定義しやすくなりました。

  <Pressable
        onPress={() => {
          // 押された回数を更新する
          setTimesPressed((current) => current + 1);
        }}
        style={({ pressed }) => [
          {/* 押されたときとそうでないときで色を変更する */
            backgroundColor: pressed
              ? 'rgb(210, 230, 255)'
              : 'white'
          }
        ]}>
　　　　　/* 押されたときとそうでないときで内部テキストを変更する */
        {({ pressed }) => (
          <Text style={styles.text}>
            {pressed ? `Pressed (${current} times)` : 'Press Me'}
          </Text>
        )}
      </Pressable>

公式ドキュメントも用意されています。

Native Colors (PlatformColor, DynamicColorIOS) の導入

PlatformColor はネイティブレベルで定義している色定義を呼び出して利用できる機能となります。

例えば iOS だと labelColor など　UIKit の UIColor でビルトインで定義されている色を呼び出すことができます。

import { Text, PlatformColor } from 'react-native';

// ビルトイン定義の labelColor 色のテキストをレンダリングする 
<Text style={{ color: PlatformColor('labelColor') }}>
  This is a label
</Text>;

DynamicColorIOS は、iOS のビルトインで定義している色の動的な変更 (ダークモードとライトモードの切り替え)に対応しています。

const customDynamicTextColor = DynamicColorIOS({
  dark: 'lightskyblue',
  light: 'midnightblue'
});

Node 8 系、iOS 9 のサポートを廃止

昨年秋、Node 8 系は LTS バージョンから落とされました (現在 Node 10系が LTS となっています)
その関係で、React Native でも Node 8 系はのサポート外となりました。

iOS 9 に関しては、シェア率が 1% 以下となったこともあり、サポートにかかるコストを考慮して、今後サポートしないことになったようです。

これによって、 React Native 内部の iOS の互換性を担保するコードのメンテナンスコストが減り、見通しがよくなったようです。

Elixir 1.6.0 の新機能の紹介

Kyoko KADOWAKI — Tue, 09 Jan 2018 02:10:54 +0000

Elixir v1.6.0 について

まだ正式なリリースはされていませんが https://github.com/elixir-lang/elixir で v1.6.0 に向けた機能が現在進行形で開発されています。現行の最新版は v1.5.2 です。

master ブランチのドキュメントはここで更新され続けています。
今回はこのうち v1.6.0 に入るであろう新機能のうち二つ

Mix Format
Dynamic Supervisor

について紹介します。

Mix Format(Code Formatter)

ドキュメント

該当ソースコード

Elixir を書いていて一番困ることの一つは公式の code formatter がないことです。

インデントずれや引数なし関数の()忘れを指摘するのは本来はヒトのやることではないです。機械にできることは機械がやってもらうのがベストです。

サードパーティのcode formatter としては ex_format や exfmt などがありましたが、スタイルガイドに厳密でなかったりコメントアウトが消えてしまうなどの不具合があり、実戦投入をするにはまだ早いかな、という感触のあるものでした。

Elixir-1.6.0 dev では Code.format_string!/2 という関数を通してプロジェクト全体のフォーマットが行えるようになります。
処理としてはstringをinputとしてCode.Formatter.algebra!によって AST に分解し、持っているフォーマット情報に基づいてInspect.Algebra.format/2によってstringに組み立て直す、ということをしています (ソースコード参照)

使い方

$ mix format /path/to/file.ex

で指定のファイルのフォーマットを行えます。

また .formatter.exs に設定ファイルを記述して、プロジェクト全体のフォーマット規約をカスタマイズすることができます。

[
  inputs: [
    "lib/*/{lib,unicode,test}/**/*.{ex,exs}",
    "lib/*/mix.exs"
  ],

  locals_without_parens: [
    # Formatter tests
    assert_format: 2,
    assert_format: 3,
    assert_same: 1,
    assert_same: 2,

    # Errors tests
    assert_eval_raise: 3,

    # Mix tests
    in_fixture: 2,
    in_tmp: 2
  ]
]

それから

$ mix format

を行うと inputs: で指定されたコードがフォーマットされます。

既存の aliases 機能を用いて

defp aliases() do
    {xxxx: ["format", "release"]}
end

などとしてビルド時など任意のタスクと一緒に format を噛ませるのもいいでしょう。

また--check-formatted オプションを付けると不正なフォーマットのファイルの存在をチェックすることができます。 (不正なファイルがあると exit 0 を吐きます) これはCIでの運用が有用だと思われます。

Dynamic Supervisor

ドキュメント

ソースコード

該当プルリクエスト

Dynamic Supervisor は子プロセスを動的に追加することができる supervisor の新しいビヘイビアです。
:simple_one_for_one の代替となるものです。既存の :simple_one_for_one 再起動戦略を持ったプロジェクトを Elixir 1.6.0 に上げる場合は Dynamic Supervisor に入れ替える必要があります。
children の指定なしで起動してあとで任意のタイミングで start_child/2 させることができます。

Dynamic Supervisor は children の link なしで start_link します。現在サポートしている戦略は :one_for_one のみのようです。

使ってみます。 Dynamic Supervisor を起動します。

iex> {:ok, sup} = DynamicSupervisor.start_link(strategy: :one_for_one)
{:ok, #PID<0.85.0>}

子を動的に追加します。

iex> {:ok, agent1} = DynamicSupervisor.start_child(sup, {Agent, fn -> %{} end})
{:ok, #PID<0.87.0>}

もう一つ追加します。

iex> {:ok, agent2} = DynamicSupervisor.start_child(sup, {Agent, fn -> %{} end})
{:ok, #PID<0.89.0>}

iex> DynamicSupervisor.count_children(sup)
%{active: 2, specs: 2, supervisors: 0, workers: 2}

:simple_one_for_one を使うときと感触は変わりません。が、　:one_for_one 以外の strategy が追加された場合どのような挙動になるのかも気になるところです。
ただモジュールベースでDynamicなことが明示されているので、それぞれの supervisor の strategy を把握しやすくなり、扱いやすくなったように感じます。

まとめ

Elixir は現在非常に活発に開発が進んでいる言語です。（そのベースとなっている Erlang/OTP もです）

ぜひ GitHub を追ったり Elixir Conf の資料を見て最新の動向を追い、その素晴らしい機能をフルに活用しましょう。