特定のinterfaceに対するinline fragment内に、interfaceが共通して持つフィールドも都度列挙して書くと、直和型の __typename フィールドによる型の絞り込みが効くようになる。逆に、共通して持つフィールドをinline fragmentの外に書くと、型の絞り込みが効かなくなる。

# OK: __typenameによる絞り込みが効く
fragment Foo_bar_ok on Bar {
  ... on Bar1 {
    __typename
    barField
    bar1Field
  }
  ... on Bar2 {
    __typename
    barField
    bar2Field
  }
}

# NG: __typenameで型を絞り込めず、bar1Field, bar2Fieldが常にoptionalになってしまう
fragment Foo_bar_ng on Bar {
  barField
  ... on Bar1 {
    __typename
    bar1Field
  }
  ... on Bar2 {
    __typename
    bar2Field
  }
}

github.com

いくつかフィールド指定のパターンを変えて試してみたけど、__typename が "Bar1" に固定されるし bar1Field も bar2Field もoptionalになってしまうケースもある*1。GraphQL Code GeneratorでTypeScriptの型定義ファイルを生成した場合はいずれのケースでも __typename による絞り込みが効く型が生成された。

relay-compilerを使っている方は気をつけてください。よきコード生成ライフを！

*1:https://github.com/utgwkk/20220606-sketch-graphql-type-emission/blob/main/relay-compiler/__generated__/Foo_foo_ng2.graphql.ts

2022-06-07

「適切な変更の粒度」とは何なのか

技術

「適切な変更の粒度」について考えることが増えたので、考えていることを流しておきます。

小さければ小さいほどよい、とは限らない

1ファイルずつ、1行ずつ変更していったらそれは差分が小さくなるけど、差分が小さければ小さいほどよい、という話ではないと思う。要はバランスです。

これまでフォーマッタが導入されていなかったプロジェクトにフォーマッタを導入する、という場面を考えてみる。ちょっとずつコードをフォーマットしていると別の変更とコンフリクトしまくることが予想されるので、一気に適用してしまう、という戦略も考えられると思う。

コードフォーマッタじゃないけど、テストフレームワークを入れ替えるときはアルファベット順に数十ファイルずつ入れ替えていく、という戦略を取ったことがある。変更が大きすぎるとコードレビューの負荷が高くなるし、変換スクリプトによる変更にバグがあったときに全ファイルやり直していくことになる、という考えでこうしたと思う。

scrapbox.io

最短ルート (1行書き換えてcommit) が常に最適とは限らない、ということもある。if文を増やしたときのことを考えてみてください。

ところでリファクタリング

id:Sixeight さんのボーイスカウトルールの記事がよかった。自分も圧倒的に先に直す派で、ちょっと難しいタスクをやるために事前に調査してこういうリファクタリングを工程に組み込みます、というのを共有しつつやっている。

blog.nishimu.land

最初に作っているうちはまだ仕様が固まっていなかったり、ドメイン知識が足りていなかったのでこう書くしかなかったけど、だんだん全容が見えてきたのでくくり出していく、というのもやっている。

ライブラリのバージョンアップ対応でどうしても大きな非互換変更が必要になるときは、新旧バージョン両方で適用できる実装方法を考えるとか、ライブラリの機能を使っている箇所をラップして互換性を保つとか、そういうことに気をつけられるとよさそう。あとは先まわりしてライブラリのバージョンだけ最新にしておくとか。

私が歌川です

@utgwkk が書いている

C100に出ます土曜日西地区“せ”ブロック－22a

「create-react-appの中身ぜんぶ見る」とは何か

C100で会いましょう

環境構築ができたなら8割完成している

■

休日

エディタ歴

EmEditor

サクラエディタ

TeraPad

Sublime Text

Mery

Atom

vim (gvim)

Visual Studio Code

relay-compilerでinline fragmentのある型定義を生成するときのコツ

「適切な変更の粒度」とは何なのか

関連する変更がまとまってると嬉しい

小さければ小さいほどよい、とは限らない

ところでリファクタリング