🤴🏿 ✌🏻 🐽 JavaScriptで予期しないデータを操作する 👩‍❤️‍💋‍👨 🥋 🤟🏼

動的に型指定された言語の主な問題の1つは、たとえば、パラメーターまたは変数をnull以外の値に強制的に設定できないため、データフローが正しいことを常に保証できるとは限らないことです。このような場合、単純なコードを使用する傾向があります。

function foo (mustExist) {
  if (!mustExist) throw new Error('Parameter cannot be null')
  return ...
}

このアプローチの問題はコードの汚染です。どこでも変数をテストする必要があり、特に変数またはパラメーターをnullにできない状況では、すべての開発者が実際にこのテストを常に実行することを保証する方法がないためです。多くの場合、そのようなパラメータの値が未定義またはnullになる可能性があることすらわかりません。これは、さまざまなスペシャリストがクライアントとサーバーの部分で作業する場合、つまりほとんどの場合に発生します。

このシナリオを少し最適化するために、私は驚きの要因を最小限に抑えるための最良の方法と方法を探し始めました。その時、エリック・エリオットの素晴らしい記事に出くわしました。..。この作品の目的は、彼の記事に完全に反論することではなく、JavaScript開発の分野での経験のおかげで私が時間をかけて発見することができた興味深い情報を追加することです。

始める前に、この記事で取り上げているいくつかのポイントを確認し、サーバーコンポーネント開発者としての私の意見を述べたいと思います。別の記事はよりクライアント指向であるためです。

すべてが始まった経緯

データ処理の問題は、いくつかの要因が原因である可能性があります。もちろん、主な理由はユーザー入力です。ただし、別の記事で言及されているものに加えて、不正な形式のデータの他のソースがあります。

データベースレコード
nullデータを暗黙的に返す関数
外部API

検討したすべてのケースで、さまざまな解決策が適用されます。後で、どれも万能薬ではないことを思い出しながら、それぞれを詳細に分析します。問題のほとんどは人為的エラーによって引き起こされます：多くの場合、言語はnullまたは未定義のデータ（nullまたは未定義）で動作するように準備されていますが、このデータを変換する過程で、それを処理する機能が失われる可能性があります

ユーザーが入力したデータ

この場合、機会はほとんどありません。問題がユーザー入力である場合は、いわゆるハイドレーションで解決できます（つまり、ユーザーが（たとえば、APIペイロードの一部として）送信した生の入力を取得して、それを使用するものに変換する必要があります。エラーなしで作業できます）。

サーバー側では、ExpressなどのWebサーバーを使用する場合、JSONスキーマやJoiなどの標準ツールを使用して、クライアント側でユーザー入力を使用してすべての操作を実行できます。

ExpressまたはAJVを使用して実行できることの例を以下に示します。

const Ajv = require('ajv')
const Express = require('express')
const bodyParser = require('body-parser')
 
const app = Express()
const ajv = new Ajv()
 
app.use(bodyParser.json())
 
app.get('/foo', (req, res) => {
  const schema = {
    type: 'object',
    properties: {
      name: { type: 'string' },
      password: { type: 'string' },
      email: { type: 'string', format: 'email' }
    },
    additionalProperties: false
    required: ['name', 'password', 'email']
  }
 
  const valid = ajv.validate(schema, req.body)
    if (!valid) return res.status(422).json(ajv.errors)
    // ...
})
 
app.listen(3000)

見てください：私たちはルートの主要部分をチェックしています。デフォルトでは、これはペイロードの一部としてbody-parserパッケージから取得するオブジェクトです。この場合、JSONスキーマを介して渡すため、これらのプロパティの1つが異なるタイプまたは形式（電子メールの場合）であるかどうかが検証されます。

重要！未処理のオブジェクトに対してHTTP422を返すことに注意してください。多くの人は、無効な本文やクエリ文字列などのクエリエラーをエラー400無効なクエリとして解釈し ます。 -これは部分的には真実ですが、この場合、問題はリクエスト自体ではなく、ユーザーがリクエストとともに送信したデータにありました。したがって、ユーザーへの最適な応答はエラー422になります。これは、要求が正しいことを意味しますが、その内容が予期された形式ではないため、処理できません。

別のオプション（AJVの使用以外）は、Rozで作成したライブラリを使用することです。これをExpressoと呼びます。これは、Expressを使用するAPIの開発を少し簡単にする一連のライブラリです。そのようなツールの1つは @ expresso / validatorです。これは基本的に上記で示したものを実行しますが、ミドルウェアとして引き渡すことができます。

デフォルト値の追加パラメーター

以前に確認したことに加えて、オプションのフィールドで送信されない場合に、アプリケーションにnull値を渡す可能性があることを発見しました。たとえば、ページとサイズの2つのパラメータをクエリ文字列として受け取るページネーションルートがあるとします。ただし、これらはオプションであり、受信されない場合はデフォルトでデフォルトに設定する必要があります。

理想的には、コントローラーには次のような機能が必要です。

function searchSomething (filter, page = 1, size = 10) {
  // ...
}

注意。ページング要求に応答して返された422エラーと同様に、正しいエラーコード206不完全なコンテンツを返すことが重要です。返されるデータの量が全体の一部である要求に応答するときはいつでも、 206ユーザーが最後のページに達し、それ以上のデータが存在しない場合、我々は200のコードを返すことができ、ユーザーが総ページ範囲外のページを見つけようとしたとき、我々はコード204を返すありませんコンテンツを。

これにより、2つの空の値を取得したときに問題が解決されますが、これは一般にJavaScriptの非常に物議を醸す側面です。オプションのパラメータは、値が空の場合にのみデフォルト値を取りますが、このルールは値nullに対しては機能しないため、次のようにすると次のようになります。

function foo (a = 10) {
  console.log(a)
}
 
foo(undefined) // 10
foo(20) // 20
foo(null) // null

情報をnullとして扱う必要があるため、オプションのパラメーターだけに依存することはできません。したがって、このような場合、次の2つの方法があります

。1。コントローラーでIfステートメントを使用する

function searchSomething (filter, page = 1, size = 10) {
  if (!page) page = 1
  if (!size) size = 10
  // ...
}

見た目はあまり良くなく、かなり不便です。

2. ルート上で直接JSONスキーマを使用する

ここでも、AJVまたは@ expresso / validatorを使用してこのデータを検証できます。

app.get('/foo', (req, res) => {
  const schema = {
    type: 'object',
    properties: {
      page: { type: 'number', default: 1 },
      size: { type: 'number', default: 10 },
    },
    additionalProperties: false
  }
 
<a href=""></a>  const valid = ajv.validate(schema, req.params)
    if (!valid) return res.status(422).json(ajv.errors)
    // ...
})

ヌル値と未定義値の操作

いくつかの理由から、JavaScriptでnullとundefinedの両方を使用して値が空であることを証明するというアイデアには個人的に満足していません。これらの概念を抽象的なレベルにすることの難しさに加えて、オプションのパラメーターを忘れてはなりません。これらの概念についてまだ疑問がある場合は、実践からの素晴らしい例を挙げましょう。

定義を理解したので、2020年にはJavaScriptに2つの主要な関数があります。null合体演算子とオプションのチェーン。これについてはすでに記事を書いているので、ここでは詳しく説明しません。（ポルトガル語です）ただし、！objなどの論理的な否定を使用する代わりに、適切な演算子（??）を使用して、nullとundefinedの2つの概念に集中できるため、これら2つのイノベーションによってタスクが大幅に簡素化されることに注意してください。それは間違いの肥沃な土地です。

暗黙的にnullを返す関数

この問題は、その暗黙の性質のために解決するのがはるかに困難です。一部の関数は、常に提供されることを前提としてデータを処理しますが、そうでない場合もあります。標準的な例を考えてみましょう：

function foo (num) {
  return 23*num
}

numがnullの場合、この関数の結果は0になりますが、これは予期されていませんでした。このような場合、コードをテストする以外に選択肢はありません。実行できるテストには2つのタイプがあります。1つ目は、単純なifステートメントを使用することです。

function foo (num) {
  if (!num) throw new Error('Error')
  return 23*num
}

2番目の方法は、どちらかのモナドを使用することです。これについては、前述の記事で詳しく説明しています。これは、あいまいなデータ、つまりnullの場合とnullでない場合のデータを処理するための優れた方法です。これは、JavaScriptには、2つのアクションストリームをサポートする組み込み関数がすでに含まれているためです-Promise：

function exists (value) {
  return x != null ? Promise.resolve(value) : Promise.reject(`Invalid value: ${value}`)
}
 
async function foo (num) {
  return exists(num).then(v => 23 * v)
}

これは、catchステートメントをexistsからfooを呼び出した関数に委任する方法です。

function init (n) {
  foo(n)
    .then(console.log)
    .catch(console.error)
}
 
init(12) // 276
init(null) // Invalid value: null

外部APIとデータベースレコード

これは非常に一般的なケースです。特に、以前に作成または入力されたデータベースから開発されたシステムがある場合はそうです。たとえば、成功した前任者と同じデータベースを使用して、異なるシステムのユーザーを統合する新製品など。

これに関する大きな問題は、データベースが不明であるという事実ではありません。実際、これが理由です。データベースレベルで何が行われたかがわからず、値がnullまたは未定義のデータを受信するかどうかを確認できないためです。 ...データベースが適切に文書化されておらず、以前と同じ問題に直面している場合、低品質の文書化について言わざるを得ません。

ここでできることは事実上何もありません。個人的には、データの状態をチェックして、データを処理できることを確認することを好みます。ただし、返されるオブジェクトの多くは単に大きすぎる可能性があるため、すべてのデータを検証することはできません。したがって、操作を実行する前に、マップやフィルターなど、関数の操作に関連するデータをチェックして、定義されていないかどうかを確認することをお勧めします。

エラーの生成

データベースと外部APIにアサーション関数 を使用することをお勧めします。基本的に、これらの関数はデータがある場合はそれを返し、そうでない場合はエラーが生成されます。このタイプの関数の最も一般的な使用例は、APIがある場合です。たとえば、識別子で特定のデータタイプを検索する場合、よく知られているfindByIdです。

async function findById (id) {
  if (!id) throw new InvalidIDError(id)
 
  const result = await entityRepository.findById(id)
  if (!result) throw new EntityNotFoundError(id)
  return result
}

EntityをUserNotFoundErrorなどのエンティティの名前に置き換えます。

これは、同じコントローラー内にIDでユーザーを検索する関数と、このユーザーを使用して他のデータ（たとえば、データベースの別のコレクション内のこのユーザーのプロファイル）を検索する別の関数を含めることができるため、優れています。プロファイルルックアップ関数を呼び出すときは、アサーションを使用して、ユーザーが実際にデータベースに存在することを確認します。それ以外の場合、関数は実行されず、ルート上で直接エラーを検索できます。

async function findUser (id) {
  if (!id) throw new InvalidIDError(id)
 
  const result = await userRepository.findById(id)
  if (!result) throw new UserNotFoundError(id)
  return result
}
 
async function findUserProfiles (userId) {
  const user = await findUser(userId)
 
  const profile = await profileRepository.findById(user.profileId)
  if (!profile) throw new ProfileNotFoundError(user.profileId)
  return profile
}

最初の関数はユーザーが存在することを確認するため、ユーザーが存在しない場合はデータベース呼び出しを行わないことに注意してください。これで、ルートで次のようなことができます。

app.get('/users/{id}/profiles', handler)
 
// --- //
 
async function handler (req, res) {
  try {
    const userId = req.params.id
    const profile = await userService.getProfile(userId)
    return res.status(200).json(profile)
  } catch (e) {
    if (e instanceof UserNotFoundError || e instanceof ProfileNotFoundError) return res.status(404).json(e.message)
    if (e instanceof InvalidIDError) return res.status(400).json(e.message)
  }
}

既存のエラークラスのインスタンス名を確認するだけで、返されるエラーの種類を確認できます。

結論

継続的で予測可能な情報の流れを確保するためにデータを処理する方法はいくつかあります。他に何かアドバイスはありますか？！コメント欄に残してください

素材のように？！アドバイスをしたり、意見を述べたり、あるいはただ挨拶したいですか？ソーシャルメディアで私を見つける方法は次のとおりです。

この記事は元々、LucasSantosによってdev.toに投稿されました。記事のトピックについて質問やコメントがある場合は、dev.toの元の記事の下に投稿してください。

JavaScriptで予期しないデータを操作する