Skip to content

Fix some typos #22

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jan 26, 2021
Merged

Fix some typos #22

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 6 additions & 6 deletions lang/TUTORIAL_JAPANESE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -712,11 +712,11 @@ GraphQLの草案は素朴なものよりもかなり良くなっていますが
`description`はすでに強い型付け（`String`ではなく`HTML`）がされており、またこれまで強い型付けを議論してきました。
しかし、繰り返しになりますが、入力は出力と少し異なる振る舞いを行うのです。

強い型付けに対する値の検証は、ユーザ空間のコードが実行されるよりも前でに、GraphQLのレイヤーで実行されます。
強い型付けに対する値の検証は、ユーザ空間のコードが実行されるよりも前に、GraphQLのレイヤーで実行されます。
つまり、クライアントはGraphQLレイヤーにおける検証とビジネスドメインレイヤーにおける検証の両方で発生するエラーをそれぞれ対応する必要があるということです。
（例えば、現状の許容ストレージ内で生成できるコレクションの上限に達した場合など）

処理を簡単にするために、クライアント側で事前に検証を行うことが難しい場合には、我々は入力対して意図的に弱い型付けを行います。
処理を簡単にするために、クライアント側で事前に検証を行うことが難しい場合には、我々は入力に対して意図的に弱い型付けを行います。
これにより、ビジネスロジックレイヤーがすべての検証を行い、クライアントも一箇所から発生するエラーだけに対処するだけで済みます。

*ルール #19: フォーマットが曖昧であったり、クライアント側の検証が複雑な場合には、入力に対して弱い型付け（`Email`ではなく`String`）を行うこと。これによりサーバーは一度にすべての検証を実行し、単一のフォーマットでエラーを報告することになり、結果としてクライアントが非常にシンプルになる。*
Expand All @@ -725,7 +725,7 @@ GraphQLの草案は素朴なものよりもかなり良くなっていますが
我々はroleの入力における`field`と`relation`フィールドに強い型付けをもったenumを用いています。
例えば`DateTime`のような特定の値入力に対しても、強い型付けを使うことがあるでしょう。

違いを生む要因はクライアント側検証の複雑さとフォーマットの曖昧さです。
違いを生む要因はクライアント側の検証の複雑さとフォーマットの曖昧さです。
HTMLはうまく定義されていて、明瞭な仕様がありますが、検証を行うには極めて複雑です。
他方で日時や日付を表現する文字列には何百の表現方法があり、それらすべてが適切にシンプルなフォーマットをもっています。
したがって、サーバーが期待するフォーマットを指定するために強い型付けを行うと便利です。
Expand All @@ -734,7 +734,7 @@ HTMLはうまく定義されていて、明瞭な仕様がありますが、検

### 入力: 構造 パート２

つづいてupdate操作をみていきます。
つづいてupdateのmutationをみていきます。

```graphql
type Mutation {
Expand Down Expand Up @@ -842,8 +842,8 @@ type CollectionUpdatePayload {
- ルール #16: 関連に対するmutationを分けて実装するときには、一度に複数の要素に対して実行することが便利かどうか検討すること。
- ルール #17: アルファベット順でグループ化するために、mutationの接頭辞に操作対象のオブジェクト名を用いること（例えば`cancelOrder`ではなく`orderCancel`とする。）
- ルール #18: mutation処理を遂行するうえで意味的に本当に必要である場合に限り、入力フィールドを必須とすること。
- ルール #19: フォーマットが曖昧であったり、クライアント側の検証が複雑な場合には、入力に対して弱い型付け（`Email`ではなく`String`）を行うこと。これによりサーバーは一度にすべての検証を実行し、単一のフォーマットでエラーを報告することになり、結果としてクライアント非常にシンプルになる。
- ルール #20: フォーマットが曖昧でクライアント側検証がシンプルな場合は強い型付け（`String`ではなく`DateTime`）を行うこと。型付けにより明確さを得られ、クライアントにより厳しい入力値管理（フリーテキスト入力ではなくカレンダーウィジェットを用いる）を促せる。
- ルール #19: フォーマットが曖昧であったり、クライアント側の検証が複雑な場合には、入力に対して弱い型付け（`Email`ではなく`String`）を行うこと。これによりサーバーは一度にすべての検証を実行し、単一のフォーマットでエラーを報告することになり、結果としてクライアントが非常にシンプルになる。
- ルール #20: フォーマットが曖昧でクライアント側の検証がシンプルな場合は強い型付け（`String`ではなく`DateTime`）を行うこと。型付けにより明確さを得られ、クライアントにより厳しい入力値管理（フリーテキスト入力ではなくカレンダーウィジェットを用いる）を促せる。
- ルール #21: たとえいくつかのフィールドの必須制約を緩和する必要があっても、重複を減らすためにmutationの入力を構造化すること。
- ルール #22: mutationはビジネスロジックレベルのエラーを`userErrors`フィールドに入れて返すこと。トップレベルのエラーフィールドはクライアントおよびサーバーレベルのエラーのために残しておくこと。
- ルール #23: すべてのエラーケースおいて返せる特定の値がないのであれば、mutationが返すほとんどのフィールドはNullableであること。
Expand Down