タイプスクリプトの適用

タイプスクリプトの適用
メインプロジェクトの再試行
再オープンコードでパブリッシュされたように、最初のプロジェクトの後にコードが再開されました.
ああ...再編成しましょうか?これは再理解しにくいコードです.しかし、問題は解決しなければならない.
まず、一番必要なものに悩んでいます.
そして決めました.タイプスクリプト.
タイプスクリプトはなぜですか?
Javascriptを使うときは悩みがたくさんあります.
コードをテストすることで信頼性を得ることが望ましいが,プロジェクトを行う過程で,上昇する不安感を本能的に感じた.

익명의 개발자: 씬프님, 이거 response 어떻게 날라오나요?
씬프: 어 잠시만요. (API 명세를 확인한다. 하지만, 업데이트 한지 오래되었다.)
   음...  진짜 잠시만요...

努力して、テストコードの上でコンソールで彼を撮って、反応中のデータを確認します.
私の考え
実際、タイプスクリプトでこの問題を解決しますか?言うことがはっきりしない.しかし、私が勉強している間に、タイプスクリプトのタイプ推定で確認しやすくなるのではないでしょうか.そう思います.
それだけでなく、パラメータタイプ、戻りタイプ、オブジェクトpropertyの推論などのタイプのスクリプトを使用すると、より安定しているようです.
もちろん、他の言語を使わせてもらえますが、javascriptという言語の特性は本当に面白いので、利用したいです.
タイプスクリプトの適用
まず、すでに多くのコードがあるプロジェクトを変えるのは難しいです.そこで,CRUD機能を持つ掲示板を作成する際にタイプスクリプトを適用することにした.
タイプスクリプトの設定

tsc --init

ありがたいことに、プロジェクトパスにコマンドを入力すると、tsconfig.jsonが生成されます.非常にフレンドリーなのは、すべての設定にコメントが付いていることです.必要に応じて注釈して使用すればよい.
しかし、設定リストが多すぎて目がくらくらします.私のようなタリンには難しすぎて...
microsoft/TypeScript-Node-Starterでは、どの設定とどの設定を使用するかを確認しながらインポートして使用します.
@types
タイプスクリプトを使用するには、使用するパッケージタイプのパッケージを整理する必要があります.@types/XXXなどの形式でパッケージをインストールすれば、タイプパッケージをインストールできます.
行こうプロジェクトに行こう.
タイプスクリプトを熟知するために、繰り返しました.
今からプロジェクトに適用しましょう!!
今まで聞いたことのないコードを書き続けています
プロジェクトでリポジトリをインポートおよび使用するときに、その内部をチェックしましたか?機能だけ持ってきて、忙しく使っています.タイプスクリプトを適用するにつれて、コードに不安を感じ始めました.
JWTタグの作成時
Javascriptを使用する場合、特定のライブラリのオプションを簡単に定義して投げ出すことがよくあります.たとえば、JWTを生成する論理を表示する場合.

  const token = jwt.sign(
    {
      exp: Math.floor(Date.now() / 1000) + 60 * 60 * 24 * 7,
      data: payload,
    },
    process.env.JWT_SECRET,
  );

JWTトークンを作成するロジックは、ネット上で使用されるコードにすぎません.使っても問題ない!作りながら使う.タイプスクリプトを適用すると、正常に動作しません.トークンの生成に使用するsign関数の定義を開きます.

export function sign(
    payload: string | Buffer | object,
    secretOrPrivateKey: Secret,
    options?: SignOptions,
): string;

signコールバック関数なしで使用すると、上記2つの必須パラメータが得られ、オプションが選択的に受け入れられます.SignOptionsの定義は何ですか.

export interface SignOptions {
    algorithm?: Algorithm | undefined;
    keyid?: string | undefined;
    expiresIn?: string | number | undefined;
    notBefore?: string | number | undefined;
    audience?: string | string[] | undefined;
    subject?: string | undefined;
    issuer?: string | undefined;
    jwtid?: string | undefined;
    mutatePayload?: boolean | undefined;
    noTimestamp?: boolean | undefined;
    header?: JwtHeader | undefined;
    encoding?: string | undefined;
}

他よりもここでexpiresInを確認しました.
私はこの時間のペイロードにデータと期限切れ時間を加えて、コインを生成しました.
しかしながら、sign関数は、それぞれ有効負荷、secret−key、optionsを受け入れる.また、expiresInを使用すると、期間を計算する必要がなく、文字で表すことで期限を定義することができる.

  const payload = { payload };
  const signOpts: SignOptions = {
    expiresIn: "7d",
  };
  const token = jwt.sign(
    payload,
    process.env.JWT_SECRET,
    signOpts
  );

タイプスクリプトを使用すると、コードの作成がより正確になるようです.
そして、私は内部でどのように操作するかに集中し始めたようです.
Multierオプションを適用する場合
ファイルを格納するライブラリMultierにタイプスクリプトを適用します.

const upload = multer({
    storage: multer.diskStorage({
      destination(_req, file, cb) {
        cb(null, process.env.UPLOAD_PATH);
      },
      fileName(_req, file, cb) {
        cb(
          null, 
          filename
        );
      },
    }),
    limits: { fileSize: 1024 * 1024 * 20 },
    fileFilter,
  }).array("photos", 4);

Multier関数は、ファイルをアップロードするとき、保存する場所、ファイル名などをオプションとしてファイルを渡して保存するときに適用できます.
タイプスクリプトを適用すると、filenameには目の釘のような下線が絶えず表示されます.🧐🧐🧐🧐🧐. 見られなくなった.
開けてみます.d.ts.

interface DiskStorageOptions {
  destination?: string | ((
  req: Request,
  file: Express.Multer.File,
  callback: (error: Error | null, destination: string) => void
  ) => void) | undefined;
  filename?(
  req: Request,
   file: Express.Multer.File,
   callback: (error: Error | null, filename: string) => void
  ): void;
}

filename....? filenameじゃない...?
これは簡単な問題です.オブジェクトのプロパティの名前を変更して終了します.
しかし、これはタイプスクリプトを書く理由ですか?
タイプスクリプトを適用するときの感想
説明した例に加えて、タイプスクリプトを適用しながらコードを再表示する場合が多い.
最大のメリットは、JavaScriptで非常に使いやすいコードとタイプを理解し、実際に内部でどのように定義され、どのように使用されているかということです.
単品書を使用していますが、_idとidの違いはわかりませんし、typeofでタイプチェックもしていませんが、使用しているようなものなので、あるので使用するものが多いです.
これにより、コードはますます予知できない苦痛になります.

if (post.author.toString() !== authorId.toString()) {
  throw new Error("권한이 없습니다.");
}

なぜこのコードはtoStringしか使えないのか...
何も知らずに使う時と違って、使う快感を知る👏🏻👏🏻_idはobjectタイプ、idはstringタイプです.コード作成時には_id,idが混在して使用されていたため,深く比較する際に問題が発生し,toStringが適用された.なぜか分からない.
和音がわからないのが怖い.
将来、ノードベースのフレームワーク(expressなど)を使用する場合、
タイプスクリプトを無条件に作成します.
次の再構築
タイプスクリプトへの変換も終了しました.
まず、追加のテストコードを作成し、テストコードが完了した場合、
サービス層に貼られたモデル機能を一つ一つ外すべきではないでしょうか.
内容はとてもプライベートな意見です.