# v2計画（Web）

## 各actionに対してのエラーハンドリング

### 原因

勢いで作ってしまったのと、エラーをハンドリングする部分を妥協した

### 解決法

調査して、適切なエラーをユーザーに表示する

## 各ページに対してapiコールを雑にしている

### 原因

ルーティングを妥協してつくったので機構をつくっていない

### 解決策

ルーティングをしている部分を再設計して機構をつくってそれに乗っ取ったpageを書く

## Atomic Designがくそ

### 原因

制作をした段階ではatomic designが世の中的にも流行っていて、良さそうに思えたが、実際運用するとくそ

### 解決策

コンポーネントを小分けにしすぎて、再利用性を求め過ぎたので、DRYを意識し過ぎずに、捨てやすいいコンポーネントの書き方をする。

https://github.com/chotchy-inc/PATRASHOP-Web/issues/784

## テストあんまり書いてない

### 原因

だるかったのと、実装に追われたため。

俺とかずきが両方とも、テストに対する知見が薄くフロントエンドのテストをどのように書くのかを明確に説明できないため

### 解決

かく。

テスタビリティの高い書き方に本体コードを書き換えないといけない。

## a11yを意識していなさすぎる

### 原因

アクセシビリティに対して関心が薄かったため、そこに労力をかけれなかった。

### 解決策

linterをいれて、今現在patraの中で治せるとこから徐々に直す。

## JavaScriptのバンドルサイズがでかすぎる

### 原因

知見不足。普通につくるとでかくなるのは当たり前

### 解決方法

バジェットを規定する。

https://developers.google.com/web/tools/lighthouse/audits/budgets

ついでにperformance budgetに対してもちゃんと規定して、それを越えるとCIで落とすなどして日常的にパフォーマンスを意識してコードを書く。