カテゴリー: 技術

2/11（火）

自宅にこもってSpotifyNowPlayingをホームページに表示する機能を作っていた。

Spotifyのaccess_tokenをredisで保持することにしたのだが、そうすると本番環境にもredisを用意せねばならない。docker-composeで連携させることになるだろうが、デプロイフローをまるごと変えなければならないので大変だ。

クライアントとサーバーのアプリケーションをどういうリポジトリ構成で管理するかも難しい問題だ。クライアントはReact、サーバーはexpressなので両方ともTypeScriptであり、型の共有などのメリットは活用したいが、両者を近づけていくとビルド周りの設定が煩雑になりそうだ。

既にサーバー側のビルドがなぜかクライアント側の型エラーで落ちる現象が起きている。おそらくtsconfigを共有しているせいでクライアント側のコードまでincludeしてしまっているからだろう。

OAuth認証も難しい。僕のSpotifyアカウントでリソースへのアクセスを許可する必要があり、これはブラウザからしかできない。よってその工程までは手作業で行ってからaccess_codeをconfに記入し、アプリケーションを起動することになる。

1/9（木）

http://www.typescriptlang.org/docs/handbook/interfaces.html

Introduction

• TSはduck typingでありstructural subtypingである

Our First Interface

• TSは要求されているプロパティがあるかだけをチェックする

Optional Properties

• プロパティ名の後ろに?をつけるとoptionalになる

Readonly properties

• プロパティ名の前にreadonlyをつけると書き換え不可になる
• ReadonlyArray<T> というやつもあるぞ

Excess Property Checks

• 要求されているプロパティがあるかだけをチェックする とoptionalを組み合わせると、optional propertyのプロパティ名のtypoが型エラーにならなくなる
• でもtypoはバグとして検出したい…検出したくない？
• なのでTSはプロパティ名を手書きする（リテラル）ときは特別に excess property checking をする
  • Object literal may only specify known properties, but 'hoge' does not exist in type 'Fuga'.
• excess property checking を回避する方法
  • as
  • interfaceの方に [propName: string]: any; を足しておく
  • 一度変数に入れる

1/8（水）

const createFakeFuga = (num: number) => ({ a: num, c: "hoge" });
const func = (array: number[]): { a: number }[] => array.map(createFakeFuga);

Playground Link

{ a: number } 型に { a: 1, c: "hoge" } を入れても怒られない。ただしリテラルで代入したときだけは怒られる。詳しくは仕様を読もう。