00:04
はい、6月29日水曜日ですね。翌朝9時を回りました。
今日も引き続き昨日に続いて、めちゃめちゃ暑いですね。本当に体調管理で気をつければと思いますね。
はい、おはようございます。イメミのkeethの福賀原です。
では本日も朝から始めていきたいと思います。
そうですね、今日は何を読むかって結局悩んだんですけど、
やっぱりウィークリーのニュース、ゲームの的なものをちょっと読んでいこうかなと思っていたので、
いろいろ探したんですけど、J3EVOは前回読んだので、今回はタイトルにある通りですけど、
Weekly Frontend Roundup from Tokyoっていうサイトがありまして、
今国内外のいろんなフロントエンド周りのニュースとかをまとめているサイトがあって、
そちらの記事を読んでいこうかなと思います。
だいたい毎週毎週10個ぐらいのリンクを持ってきてもらって、
それについてざっくり概要が書いてあるわけですね。
それだけ読むと一瞬で終わってしまうので、どれか1個をピックアップして、
詳細な記事を読んで内容に入っていけたらなというふうに感じます。
では早速読んでいきたいなと思います。
1つ目は、System Thinking is What Makes Designers Greatってことですね。
デザイナーのためのシステム思考っていう記事のタイトルですね。
概要でいくと、デザイン思考がデザインに対してどのように影響するのか。
経験の浅いデザイナーが作るデザインっていうのは、
1つのニーズを満たす代わりに他の12のニーズを生み出してしまうと。
1個解決するけどその代わり12個、次の課題が出てくるということですね。
優れたデザインっていうのは、エコシステム内の他の何かに悪影響を与えることなく問題を解決する。
優れたデザイナーになるためには、優れたデザインを作成するためには、
どのようにシステム思考を適用していけばよいかっていうのを解説していくよっていうことでした。
2つ目のリンクですけど、ディフェンシブAPIハンドリングっていうですね。
防衛的なAPI処理っていうふうに書いてますけど、
こちらはJavaScriptでいわゆるフェッチを利用したAPI処理を実装する際に、
どういった点を考慮すべきか。
フェッチの仕様を確認しながら、その仕様に合わせた正常系の実装と考慮すべきエラーハンドリングを段階的に実装する。
実装式の流れっていうのを解説していくよっていうことでした。
これはちょっと気になる。
1つ目のデザイナーのシステム、すごく僕は個人的には気になりますけど、
フロントエンドの目線からこのAPIの処理、防衛的なAPI処理っていうのの実装を段階的に見ていくっていうので、
これはフロントエンドエンジニアとしても勉強しそうになると思うので気になりますね。
続いて3つ目です。
3つ目はHow to pick the list of wrong colorsってことですね。
データ資格化用のカラーパレットを作成するためのアルゴリズムっていうことです。
ストライプのデザイナーがシステムのグラフのデザインに対してアクセシビリティの目標を達成しながら、
03:04
カテゴリーデータの幅広いユースケースをカバーする。
美声の良い色を選択するにはどうすればいいかっていうのを考察してるっていうことですね。
いやー、これも全部気になるなー。
全部読んでいくと多分キリがないのであれですね。
ただこれも気になるんですけど、おそらくカラーパレット的なのがだんだん出てくるので、
記事内に結構色っていうのがすごいいっぱい出てくる気がするんですよ。
色っていうか図ですね。図がいっぱい出てくると思うので、
割とちょっと口頭で説明するにも限界がある気がしなくもないなっていう感はありますが。
いいですね。まずは続きいきましょう。
続きは4つ目ですね。
4つ目は、Base Layers and Design Principlesですね。
ベースレイヤーのモデルがウェブ、そしてデザイン原則に対してどのように適応できるのかっていうのを解説した記事だそうですね。
結構今回はデザイン周りが多いですね。
もしかもそもそもこのサイト自体がデザイン周りに結構関心とかが強い方がピックアップしているのかもしれないですけど。
続いて5つ目。
5つ目はオンデザインシンキングですね。
デザイン思考がどのようなものか、またそれがどのようにワークするのか、どのようにワークしないのかっていうのを解説していきましょうということですね。
まあまあちょっと個人的には気になるところばっかりですね。
で、残りですけど残り5つざっと、インブリフでざっとまとめてありますね。
6個目ですけど、6個目はUnderstanding Weak References in JavaScriptということですね。
JSの強い参照、弱い参照についてその使用を説明しますよということですね。
で、7個目です。
7個目はProcessing Arrays Non-Destructivelyですね。
Destructivelyですね。
破壊的変更じゃないやつですね。
For All Versus Reduce Versus Flat Mapですね。
非破壊的な排列の操作であるFor AllとReduceとFlat Mapの比較をとりあえず行ってみましょうということでした。
で、8つ目ですね。
8つ目はBuilding a Design System with Eleventyですね。
Eleventyっていうライブラリーがあるんですけど、そのEleventyでデザインシステムを実装するための方法ということですね。
Eleventyっていわゆる静的なサイトを作るためのジェネレターですね。
結構ダウンロード数多いし、これ自体もかなり使いやすかったので、僕Eleventyかなり評価高いです。
いろんなライブラリーの公式サイトでも確か使われてた記憶があります。
で、9つ目ですね。
9つ目はHow Designers Can Become Better Managersということですね。
デザイナーがマネージャーになるためのチップスを今回紹介しているという記事ですね。
ラスト10個目ですけど、キーボードオンリースクローリングエリアということですね。
キーボードのノビでスクロール可能なエリアをアクセシブルにするためのアイディアを紹介するということでした。
06:01
以上、合計10個の記事ですね。
ザーッと今回のWeekly Frontend Roundup From Tokyoというところから見つけましたけど、
実に、1、2、3、4、5、6ですね。
10個中6個がデザイナーのための記事だったりするので、
お借りしている身としては別に何も不満がないですけど、
ちょっと癖が強いというか傾向がデザイナー寄りなんだなという感じです。
今回たまたまかもしれないですけど、
別にまだ他の日付の時の10個のピックアップを見てないんですけど、
今回はとにかくデザイナーのためのものが多かったということですね。
気になるものでいくと、僕は3つ目かな。
3つ目のデータ資格化用のカラーパレットを作成するためのアルゴリズムというところですね。
ストライクのデザイナーがシステムのグラフのデザインに対して
アクセシビティの目標を達成しながらというやつです。
これが僕はちょっと気になるんですけど、
軽くザッと開いてみたんですけど、
ひたすらに、確かにテキストがバーってあるので読むことはできるんですが、
途中途中はちゃんとグラフとか図がいっぱい出てきていて、
これについて説明をしているので、
あんまり高等だと伝わらない感がすごく強いので、
読むのが悩ましいのと、あとは結構ボリューミーなので。
一旦そこはやめといて、
他のものを読みたいんですけど、
他のものになると急にソースコードがいっぱい出てくるものが多くて、
悩ましいので、やっぱり抽象的といいますか、
思考とか、いわゆる頭で考えるフィロソフィー的なものを読んでいこうかなと思うので、
一番良さそうだというか、
ソースコードもなく図もほとんどなかったというところで、
一発目ですね。
デザイナーのためのシステム思考の記事を読むかと思います。
システムシンキングis what makes designers great
記事を読んでいこうかなと思います。
いつも通り、とりあえずまず翻訳にかけるので。
これはそんなに長くないので、時間が余る可能性が大いにあるので、
時間が余ったら違う記事を読んでいこうかなと思いますね。
では、入っていきましょう。
今回の記事を書いた方は、
クリステンセン・ターナーさんですね。
はい、では入ります。
私は以前、優れたデザイナーは、その技術によって
触れるもの全てに洗練とスタイルを加えているのだと信じていました。
しかし今では、優れたデザイナーは細部へのこだわりだけでなく、
自分の仕事について総合的に考える能力があるからこそ、
これほどまでに素晴らしいのだと理解しています。
個人的には、優れたデザイナーだとしても、
両方ともやっている気がしました。
09:01
全てに洗練とスタイルを加えているというのもそういう風に感じますし、
細部へのこだわりもしっかり持って、
総合的に考える能力もあるという風に思ったりしていますので、
本当に優秀なデザイナーだとしても、
両方やるんじゃないかと思ったりはしていますね。
ただ、紙や細部に宿るというところは僕は重きを置いていて、
特にデザインに関してはそれが本当に顕著に現れるのかなと思います。
ユーザーが結局目で見たり、実際に触ってみて、
その中で細部までしっかりデザインされていると、
ユーザーはストレスなく体験によく触れていると思いますけど、
やっぱり微妙なところにサボったりしていると、
ここだけちょっと不満だよねというのがたまるんだと思いますね。
同じウェブサイトであったり、
Webアプリケーションを使うにおいても、
細かいところの小さなストレスが少したまっていって、
このサイト微妙という風な評価になる気がしています。
これは個人の考えです。
すみません、戻りますね。
昔、私はドリブルとかビハンスとかを見て、
そこで目にする美しい美学とかアニメーションにすごく関心をしていました。
ロゴとかウェブサイト、アプリデザイン、キャラクターイラストなど、
スタイリッシュでトレンディーな作品のポートフォルエを見ていたのです。
感性の高い作品に出会うたび、これは良いデザインだと思っていました。
デザインとは目に見えるものをきれいにすること、
つまりプレゼンテーションが重要であるかのように捉えられがちです。
はい、そうですね。
これはデザインの世界以外の人から見るとアートと同じような視点になります。
私たちはアートをその外見で称賛する傾向があります。
そうですね、すごく思います。
Appleが美しいものを作り、それをGreat Designというベールの下で誇らしげに見せているのは有名な話です。
これは見せ方の話とかプレゼンの仕方の話だと思います。
良いデザインというのは、磨かれた工芸品であるという考え方は、
あるレベルでは一定正しいと思います。
しかし、私がこれまで学んできたのは、
優れたデザイナーはプレゼンテーションだけでなく、
作品について全体的に考えることができるということです。
画面やキャンバスに描かれたデザインだけでなく、
その先を考え、想像する鋭い能力を持っているのですというふうに言っていますね。
はい。
今のところおおむね同意というか、確かにそうだなという感じがありますね。
続きますね。
経験の浅いデザイナーというのは、
自分の作っているものの中だけで考えてしまいがちです。
作っているものを深く理解することは、
それを強化することになると聞いていますが、
しばしば焦点を絞るため、作品を世に出すと、
それがどのように壊れてしまうかを理解できません。
うーん、なるほどですね。
壊れることを意識するのか。
エンジニアならよくわかりますけど。
デザインも壊れるという概念で考えるんですね。
このような未熟なデザイナーが作るデザインというのは、
例えばその障害のある人に出会ったとき、文脈から外れたり、
12:00
サイズや時間によって歪んだりして立ち行かなくなることがあるのです。
想像の範囲を超えたようなユーザーが来たときに、
途端に壊れるということがあった。
まずしいデザインというのは、一つのニーズを満たす一方で、
他の多くのニーズを乱しているのです。
良いデザインはそのエコシステムの中で、
他のものに悪影響を与えることなく問題を解決します。
私たちはこのような考え方をシステムシンキングと呼んでいます。
これは純粋に偉大なデザイナーとかなり偉大なデザイナーを分ける傾向があります。
偉大な中でもさらに強弱があるんですね。
はい、はい、はい。
面白いな。
で、で、で。
ちょっと見失りましたが。
はい。
素晴らしい仕事をするデザイナーというのは、
自分たちが作っているものが泡の中に存在するのではないことを知っています。
彼らは自分たちが作っているものがチームがどのように作るべきかについて、
その文脈が重要な役割を担っていることを理解しているのです。
いいですね。
コンテキストが文脈を理解していると。
自分たちが作るものがそれぞれ、それが触れるものにすべて、
特に人々にどのような影響を与えるかというのも知っています。
デザインは意図的なものになりますと。
トレードオフを把握し、重みづけをし、決定する。
それはその場の問題だけでなく、周囲の空間も含めてですと。
これは結構よく聞きますね。
いろんなデザイナーとか、別にウェブデザイナーだけじゃなくて、
プロダクトデザインとかもそうですし、建築のデザインとかもそうですし、
いろんなデザイナーの方の書籍とか、記事であったり、
僕はパラパラ見ているんですけど、
結構皆さん似たようなことを確かにおっしゃいますね。
本当に。
はい。
デザインは絶対に意図が入っているし、
どういう意味でこれをこういうデザインしたかというのを説明できるというのも言っていましたし、
その見た目とかその場、対象物オンリーだけで考えるんじゃなくて、
その周辺とか周りとか、ユーザーのどういうふうに動いていくのかみたいなところも含めてデザインをしていると。
その中でトレードオフをして、重みづけというかここに重きを置いていますみたいなことを、
やっぱりいろんなデザイナーさんがおっしゃられているので、
ここはそうなんだなと思いますね。
はい。
割となんかやっぱり建築系のデザイナーは特にこの発言をおっしゃられますね。
思いっきり空間を扱うので、もろにそういうところと向き合っているんだなと思いますけど。
はい。
で、続いていきますね。
もしあなたが平均的なデザイナーになりたければ、
自分が作っているものの周りにある狭い視野に焦点を当ててみましょう。
自分の作ったものが業界やそれを様々な立場で使ったり、
出会ったりする人々にどのような影響を与えるかについて、
気にしないことです。
本当に狭い視野でまず焦点を当てて物事を見ましょうと。
そのデザインを進化させなければならない人たちや、
後から来た人たちがそれに手を加えることも気にしなくていいと。
そういうことをしていけば、とりあえず平均的なデザイナーにはなれるよと。
一方で、狭い範囲に留まらない影響力を持つデザイナーを目指すのであれば、
15:01
自分のデザインが誰にどのような影響を与えるのかを
常に考えながらプロセスを磨いてくださいと。
これには様々な方法があり、
いくつかはインターネット上で詳細に記録されています。
自分の作品の最も単純なバージョンと、
最も複雑なバージョンの極端を作り上げること。
それはあなたがそれをやったというためではなく、
それらの極端なものが文脈の中でどのように見えるか、
または感じられるかを自分で感じるためですね。
作品を共有することは常に念頭において構築する。
たとえそれが実現しない場合でも、
とにかく共有する、公開することを念頭において構築しましょうと。
チームで作業をしている場合は、
作業ドキュメントに十分なメモやコメントを残しておくことで、
早くから頻繁に作品を共有することができます。
これとエンジニアも一緒ですね。
コード途中でドラフトのプルリクエストを出したりして、
今こういう方針でやってますよとか、
コードだけをチャットとかスラップで共有しておくこともできたりしますよね。
単独で作業している場合は、とにかくコメントを残しておくことです。
いつ昔の仕事に戻らなきゃならないか分かりません。
その時に文章と構造化された文章があれば、
どれだけ早くその仕事を再開し、理解できるようになるか分かりません。
これも本当に同意ですね。
コメントはめちゃめちゃ大事ですね。
ただコメントって何をやったかっていうコメントを残すのはぶっちゃけあまり意味なくて、
今から読むコードのどういう意図で、
なんでこれがこうなっているとか、
どういう意味でこういうプロパティが加わったとかっていうその意図を書くことがコメント文なので、
やったこととかその下に書いているソースコードがどういうことを今から処理しますかみたいなことを書くのは正直無意味だと僕は思ってます。
できるだけ頻繁に他社にフィードバックを求め、
その人の作品があなたの作品に対する視点をどのように形成しているか、
質問や好奇心を持って参加してもらいましょうと。
あなたのデザインが存在する必要のあるより大きなエコシステムに目を向けることで、
一貫性と親しみやすさのためにより見栄えする、より機能的なものを作ることができます。
そしてそれこそが驚異的なデザイナーになるための条件なのですというところで締められていますね。
ちょっと短いですけども、わりと面白かったなと思います。
デザインシステムそのもの、システムシンキングか。
システムシンキングというところの観点はやっぱり、
僕らエンジニアでは当たり前のようにインストールされていますけど、
そこはやっぱりデザイナーさんたちの思考プロセスとか端が違ったりするので、
その視点を改めて文章化、言語化されているのは結構面白かったですね。
とにかく細部のことに注目を置いていて、なおかつでもトレードオフでどこにも見つけをして、
かつそれが周りの空間とかその対象物以外のところまでどんな影響があるかというのも
18:01
考えながらデザインをしていくというところですね。
その上でドキュメントもしっかり残していくし、なるべく小さくても早く共有をどんどんしていって、
レビューをもらってというところです。
とてもはっきりした言語化をされていて、ものすごく読みやすかったし、
わかりやすかったなと思いますね。
やっぱりこんなところまでしっかり考えなきゃいけないということを考えると、
改めてデザイナーさんというのは本当に価値の高いという、
そして難易度も高いお仕事をされているなということを痛感したなという感じがしますね。
じゃあ続いてですね、残り10分。
10分で読めるものですけども、やっぱり後半のほうはですね、
ひたすらソースコードだらけな記事ばっかりだったので、悩ましいんですが、
そうすると結局デザイナーのための記事ばっかりになっていく形ですね。
一番気になっているのはディフェンシブAPIハンドリングってやつですね。
JavaScriptでフェッチを利用したAPI処理を実装する際に、
どういった手を考慮すべきかというところですね。
防衛的なAPI処理というのをどうやってやるか。
その正常系と異常系、エラーハンドリングを段階的に実装していく流れを解析していくということなんですけど、
この記事すごく読みたいんですが、めっちゃソースコードだらけなんで、
かつちょっと長いね、中途半端になりかねないんですけど、
まあ行ってみるか。
どうせ気になっているので。
じゃあこっち行っていきたいと思いますね。
途中で出てくるソースコードはなるべく高等になってしまうので、
ラジオ的に聞いてもらえたらと思います。
頭の中でソースコードをイメージしていただいても全然いいですけど。
はい、じゃあ行きますね。
この記事ちょっと古いですね。
5月31日に書かれた記事ですね。
スコット・バンディフィーって人ですね。
読み方はわからないですけどね。
では行きます。
最近のクライドプロジェクトでは、
サードパーティーの登録サービスに送信するフォームがありましたと。
いっぱいあると思いますけど。
APIに関するドキュメントが送られてきたので、
そのフォームを作成しました。
簡単でしょと。
しかしその後、APIを安全に扱うための素晴らしい教訓となる、
一連の滑稽な事件が発生しました。
ここではAPI接続をより強固なものにするために、
追加できる一連の安全性チェックが必要となりました。
一連の安全性チェックについて説明したいと思います。
私が説明するシナリオのいくつかは、
エッジケースのように感じるかもしれませんが、
これらはすべて私たちが遭遇した現実の状況に基づくものです。
これらのいずれかが原因で、
登録フォームのようなアプリが失敗し、
ユーザーにはウェブサイトが壊れているようかに見える、
あるいはもっと悪いことに、
本当は失敗しているのに、
登録が成功したかのように思える可能性があるのです。
それは怖いですね。
なかなかそうですね。
登録フォームは単純ですけど、
そんなに簡単でもないし、
割とフォーム自体はいろんなことを考慮しなければならないので、
特に僕はよくやりますけど、
21:00
ログイン画面ってあるじゃないですか。
ログイン画面にどれくらい見積もりしますかとか、
どれくらいコースがかかりそうですかというのを結構聞いたりします。
やっぱりあまりウェブシステムとか実装とか、
技術的なところに明るくない方というのは、
ログイン画面って一瞬で作れるってみんなおっしゃるんですけど、
僕ログイン画面で下手したら1週間余裕でぶっ飛ぶと思うんですよね。
そもそも認証周りどうするのというだけでめちゃめちゃヘビーですし、
デザイン周りもしっかりしなきゃいけないし、
エラーハンドリングどうするのというのは絶対あるし、
バリデーションを側でもやるのかという話もあるし、
どこまでバリデーションするんですかというのもあるし、
実装だけじゃなくて、
決めなきゃいけない仕様とかコミュニケーションが大量にあるんですよね、
ログイン画面って。
自分によくあるメールアドレスとパスワード入力ってだけかもしれないですけど、
めっちゃ裏に考えることあるんですよねっていうのはあったりしますね。
すみません、全然余談でした。
じゃあ行きましょう。
ベーシックAPIポストってところで、
基本的なAPIの投稿からです。
ここに登録関数の最も基本的なバージョンのソースコードを置いておきます。
フェッチメソッドを使って登録APIにポストリクエストを送って、
APIのJSONレスポンスをデコードしてJavaScriptオブジェクトにして、
それを返すことができます。
ソースコードゲームはそうですね、
asyncで関数がとりあえず定義してあって、
引数にボディとなるオブジェクトを2つ受け取ってますと。
で、初っ端フェッチをしてますね。
awaitかけておいてフェッチですね。
なんか適当なURLがあいといて、
メソッドポストにヘッダーをとりあえずコンテンツタイプ、
アプリケーションJSONとキャラセットUTF8をつけておくと。
で、ボディに先ほど見た、引数に受け取ったユーザーオブジェクトを
JSONStringifyにかけてJSON化して投げてますよと。
で、受け取ったものをやっぱりawaitで
response.jsonというメソッドでJSON化に戻して、
で、それをリターンしてますという感じですね。
とてもシンプルなAPIポストです。
ここ、別にフェッチAPIでもいいし、
なんかAXIOSみたいなのを使う方もいらっしゃると思います。
その辺はご注意に、
適宜読み替えていただければと思うんですね。
で、チェックIf the API response is OKということで、
API responseに問題がないかをとりあえず次に確認しますと。
次のコードは、
APIサーバーが信頼できるものであれば問題なく動作はしますと。
しかしフェッチメソッドでいつも気になるのは、
サーバーが完全にオフラインの場合のみ失敗するという点です。
つまりサーバーがエラーを示す
Statusコードで応答した場合、
フェッチはその接続を成功したとみなし、
エラー応答を喜んで渡しますと。
で、APIサーバーから受け取る可能性のあるエラーには
どのようなものがあるでしょうかと。
我々が遭遇したことがあるものについては、
いわゆる403、503がありますと。
403エラーというのはアクセストークの適切な認証情報を
渡さなかったことを意味します。
そうですね、forbiddenですからね。
で、503エラーはAPIサーバーが利用できないが、
サーバーはオンラインである場合に返されるかもしれません。
どちらの場合もフェッチリクエストというのは
受け取ったエラーを返して成功したことには一応なりますと。
難しいですね。
接続は確かにできているのは事実ですよね。
ちゃんとエラーが返ってきてますからね。
24:00
502とかゲートウェイが死んでいるとかになったらまた
ちょっと別の話だと思いますけど。
はい。
あとなんだっけ。
このような場合、私たちのコードはサーバーエラーを含む
APIレスポンスを返すことになり、アプリケーションをすると
どうすればいいのか分からなくなりますと。
幸いなことにレスポンスにOKプロパティが含まれているかどうか
チェックすることで、かなり簡単に対処することはもちろんできますと。
これは成功した応答の省略記法で、サーバーからステータスコードが
200の範囲にある場合に真となります。
そうそうですね。
はい。
具体的なソースコードも、さっきとほぼ同じコードですね。
フェッチ投げてURLとオプションを渡してあげて、レスポンスを受け取って。
そのレスポンス.OKというプロパティを見て、それがOKであればリターンですよと。
違う、リターンじゃなくて、OKであれば次の処理に移って
レスポンスをJSONにして、そのJSONを返します。
もしレスポンス.OKがフォルシーな値だったら
単純にリターンをしますみたいなソースコードになってますね。
ちょっとこれは握り潰している感がありますね。
はい。
続いてのセクションですけど、ハンドルエラーですね。
エラーの処理をしましょうと。
この時点でJavaScriptがエラーを投げる可能性のある場所は2つあります。
1つ目は最初のフェッチリクエストに失敗した場合と
2つ目はJSONのdecodeステップに失敗した場合です。
先ほど説明したように
フェッチリクエストはAPIが全く利用できない場合にのみ失敗します。
じゃあなぜJSONdecodeの段階で失敗するのでしょうかというところですけど
設定ミスしたAPIがサーバーエラーを通過して
500のステ出すコードを返すのではなくて
200のステ出すコードを返して
レスポンスのボディはサーバーのエラーページの
HTMLコンテンツであると想像してくださいと。
このコードでは200を確認し
decodeするためにJSONに、JSONメソッドにレスポンスを出しますが
レスポンスがそもそもJSONじゃないから失敗をするということですね。
要は意図しないデータ形式になるので
JSONメソッドというのがそもそも失敗するということでした。
この辺も皆さんご経験あると思いますね。
この場合スクリプトの実行が停止し
ページが壊れる可能性があります。
ユーザーにとっては悪い経験になってしまいます。
しかしこのようなことが起こる場合
起こるかもしれないことを知っているので
try-catchのステートメントを使用することができます。
そうすればコード内で何かエラーが発生した場合
そのエラーはキャッチプロジェクトに渡されて
そのアプリが壊れないように処理することができます。
今言った通りのソースコードが今出てきてますね。
フェッチしてレスポンスを受け取って
レスポンス.okがそもそもフォルシーだったら
スロー入エラーでレスポンスのエラーステータスの
表示しています。
okであればawaitのレスポンス.jsonメソッドで
JSON化します。
で、return jsonします。
ただこれ自体try-catchしてやって
キャッチの方でコンソメログの
とりあえずエラーメッセージを出しているみたいな感じですね。
1個だけ注意があって
レスポンス.okのチェックも
returnではなくてエラーを投げるに今回は変更してますけど
27:00
これで3つのエラーの状態を
カバーすることができましたということですね。
そもそもですけど
フェッチしてましてレスポンスのところが
正直に言うとエラーならば
ステータスコードを400系500系に返してもらうような
APIであれば何も問題はなく
そのままハンドリングできるんですけどね。
でも200okでボディがエラーだったりするので
よくある話なので
この実装が現実的には確かに
よくやることかなという気もしますけど
ここは本当にAPIチームと
もしコミュニケーションできるのであれば
実装の話はちゃんと話した方がいいと思いますし
エラーパターンについては
APIとの使用の決めをした方がいいと思いますね。
じゃあ次々いきます。
あと1分ちょいなんですけど
記事的に確かにちょっともう
コンクルージョンに近いので
ちょっと時間オーバーしますけど
読み切ってしまいたいなと思います。
時間許す方はお付き合いいただければと思います。
では続いて
check if the response is ok but contains an error
ということですね。
レスポンスは問題ないけど
エラーが含まれてないかというのをチェックしましょう。
さてAPIに何か問題があった場合
適切なレスポンスステータスが変えられるはずですと
200番台のレスポンスというのは
全てが順調であることを意味します。
しかしおそ松のAPIでは
JSON時代にエラーが含まれていても
200のステータスコードを変えることが
驚くほどよくあります。
驚くほどよくあることは我々の経験通りです。
これはサーバーのエラーはないものの
リクエストに何か問題があった場合に送ります。
サーバーが登録を保存できなかったのかもしれないし
あるいはそのユーザーが
すでに登録済みかもしれませんね。
これらがシナリオをカバーするための
ステータスコードがありますが
多くのAPIは200とエラー
またはエラーズプロパティを含む
JSONレスポンスを変えしますねと。
この状況はコードに別の安全性チェックを
追加することで対処できます。
もしこれらのプロパティの
いずれかをレスポンスで見つけたら
エラーを投げることができますよということで。
コードを見てますと
さっきのコードをさらに拡張してますね。
トラックキャッチで挟んであって
まずトライのここでフェッチを投げてます。
レスポンスのOKの値がフォルシーか
確認してますと。
フォルシーになったらもちろん
スローニューエラーしてますと。
OKならば続いて
アウェイトして
レスポンス.JSONメソッドで
JSONを受け取って
JSON.ERRORを見て
エラーが入ってんだったら
スローニューエラーで
JSON.ERRORをそのまま返します。
JSON.ERRORSですね。
ERRORSみたいな値です。
オブジェクトが
っていうものが入ってるんであれば
スローニューエラーで
JSON.STRINGIFYして
JSON.ERRORSっていうのを
スローしちゃいますと。
何も問題なければ
そのままリターンJSONオブジェクトを返しましょうと。
エラーとERRORSっていう
2つのパターンも確かにあり得ますからね。
めんどくさいなと思いますけど。
最後、キャッチで
キャッチは好きに
エラーハンドにしてくださいっていうことでした。
ここもちょっと注意書きがありまして
あなたのAPIが同じプロパティを送信すると
仮定しないでください。
エラーが発生したときに
何を送信するかを確認して
このチェックを更新して位置させましょうと。
確かにそうですね。
そもそも投げるときのプロパティも
確認してくださいってことでした。
30:00
この場合APIのドキュメントによると
文字列を含むこのERRORプロパティを返すか
ERRORS配列かを返すかの
どちらかだそうです。
このERRORっていうのは
文字列が渡されることを想定しているので
私はERRORS配列の構造を知らないので
とりあえずJSONエンコードしています。
ドキュメント化してるんであれば
いろんな渡し方あげますけど
とりあえずは一旦JSON
Stringifyで返してみます。
形式がわからないとそりゃそうかもしれないです。
続いて
Check if the response is what we were expecting
期待通りのレスポンスがどうかチェックしましょう。
最後にですね
もう一つだけ確認することがありますと
時には成功したレスポンスが返ってきて
その中にERRORが含まれていないこともあります。
例えば一つのレコードを更新することを
意図したエンドポイントというのは
複数のレコードを返すように
簡単に設定することができてしまっていて
セキュリティとパフォーマンスよって
結構最悪ですよって言ってますね。
その結果レスポンスが期待しした
プロパティを含んでいるかどうかをチェックすることは
かなっているよねっていうことでした。
引き続きさっきのソースコードを拡張してあって
今回やっていることは
if文が1個挟んでますね。
ERRORとERRORSまで見ているんですけど
次に見ているのがJSON.COUNTですね。
件数を見てそしてJSON.RESULTSを
アッパーサンドに挟んで見ています。
それらを挟んだものがフォルシーであるか
っていうのを確認してますね。
あればスローニューエラーを押して
The API returned unexpected response
っていう風なエラーを投げてますね。
そういうことの処理をしているという感じです。
ここも一応ノートがあって
注意書きがあって
JSON.COUNTとJSON.RESULTSというプロパティは
あくまで例ですよと。
皆さんが利用するAPIのプロパティに
置き換える必要がありますよということですね。
とにかく自分たちが意図しないプロパティか
JSON.COUNTをif文でチェックしてるということですね。
最後、コンクリューションを読み切って
終わりにしようかなと思いますね。
じゃあコンクリューションの結論ですね。
まとめです。
はっきり言って以下の問題全て実際のもので
遭遇していますよと。
そもそもAPIが応答しませんと。
APIが400または500のステータスことで応答します。
200で応答するけど応答はJSONじゃないですと。
APIが200で応答するんですけど
その応答にはエラープロパティがあります。
最後ですね。
APIは200で応答するけど応答には
予期しないコンテンツが含まれていたりします。
これのどれもあり得ると思いますし
外部APIを使うときはこれのパターンがあることを
僕らはフロント側は想定して実装しなきゃいけないことですね。
ユーザーが登録しようとしたときに
これらのいずれかが発生すると
アプリがクラッシュしたり
さらに悪いことに実際には失敗しているのに
成功したように見えたりするのは結構困りますよね。
このコードではこのようなシナリオを検出し
33:00
ユーザーに役立つメッセージを表示しています。
完璧な世界であれば
このような安全性のチェックは必要ないでしょう。
理想を言えば全てのAPIが標準を尊重し
適切なステータスコードで応答していることでしょう。
しかし我々は完璧な世界に生きているわけではないので
残念ながらAPIが予期せずにフルオンラインしたときに
その代償を支払うのはユーザーなのです。
なのでたとえそれが少しやりすぎだと感じたとしても
APIから期待するものを受け取っていることを検証するために
安全のチェックを追加し
途中で遭遇するかもしれないエラーを処理するのは
懸命なことでありました。
なるほどですね。
タイトル的には
本当はAPIの実装の話かなと思ったんですけど
APIを使うフロント側の実装の話だったんですね。
ということでした。
よくやることだし
僕らも何度も遭遇したことだと思うので
復習程度になったかという感じですね。
そういうことはないですけど
これをちゃんと言語化しておくというのはすごく大事なことですし
僕らはそういうことを段階的にやってますよということも
何ですかね、外に公表していくのもいいことだと思いましたね。
フロントエンドはどんどん複雑化していまして
クライアントAPI形式で実装していくというのは
今後もうちょっと続くと思いますね。
SPAの時代はもう少し続くとは思っていますし。
意外と今フルスタックのフレームワークが
もう一回流行し始めていて
フリッツだったりとかレッドウッドJSとかみたいな
本当にフルスタックのフレームワークがもう一回出てきて
揺れ戻しが起こっている感もあるので
その中でも結局サーバー側とのやりとりは
やっぱりAPIでやるっていうことはあんまり変わってないので
もう少し続くんだろうなと思います。
という意味で改めてこういうハンドリング周りっていうのを
段階的にやっていたっていうのがいい記事だったなと思いましたね。
なるべくユーザーにそういう影響がないような実装を
僕らも心がけていきたいなと思いましたね。
というところでちょっと時間が過ぎましたけど
こちらでじゃあ今朝の朝活は以上にしたいかなと思います。
ご参加いただいた4人の皆さん本当にありがとうございました。
また次回もですね、読むネタがなくなったら
今日見たウィークリーフロントエンドラウンドアップですね
fromTOKYOさんの記事をまたダラダラ読んでいこうかなと思いますので
いろいろとご参加いただければすごく幸いなと思います。
じゃあ今日の朝活はこちらで以上にしたいと思います。
はい、水曜日ですね。中日ですけど頑張っていきましょう。
お疲れ様でした。
