Next Actions
余裕があれば挑戦してみましょう。
コードフォーマットを実行する
複数人で開発する場合には、全体の品質を保つために、各々が好きなスタイルでコードを書くことを避けるべきです。
コードフォーマットツールのデファクトスタンダードである Prettier を利用し、各ファイルが統一されたフォーマットに修正されることを確認しましょう。
ルートディレクトリに .prettierrc ファイルを新規作成し、次のコードをコピペします。
{
"printWidth": 80,
"tabWidth": 2,
"useTabs": false,
"semi": true,
"singleQuote": true,
"quoteProps": "as-needed",
"jsxSingleQuote": false,
"trailingComma": "none",
"bracketSpacing": true,
"jsxBracketSameLine": false,
"arrowParens": "always",
"requirePragma": false,
"insertPragma": false,
"proseWrap": "preserve",
"htmlWhitespaceSensitivity": "css",
"endOfLine": "lf",
"overrides": [
{
"files": "*.html",
"options": { "parser": "lwc" }
}
]
}package.json の scripts に prettier コマンドを追加します。
prettier をローカルにインストールし、実行します。
それぞれのファイルでコードがどのように修正されたのかを確認します。

静的コード解析を実行する
コードフォーマットを合わせたら、次はコードの書き方にこだわりましょう。せっかくコードを書くのであれば、先人の叡智が詰まった規約に準拠した書き方をお勧めします。潜在的なバグを事前に潰しておくことにも繋がります。
JavaScript の静的コード解析ツールのデファクトスタンダードである ESLint を利用し、コードが規約に違反していないかどうか確認しましょう。
ルートディレクトリに .eslintrc.json ファイルを新規作成し、次のコードをコピペします。
package.json の scripts に eslint コマンドを追加します。
eslint をローカルにインストールし、実行します。
それぞれのファイルでコードがどのような警告が表示されるのかを確認します。

また、.reports フォルダ内に生成されている eslint.html をブラウザで開くと、警告を一覧表示することができます。

コードを修正し、警告が消えたことを確認します。


Lightning Design System を適用する
今回のチュートリアルで作成された画面はとてもシンプルですので、Salesforce の標準的なスタイルを適用してみましょう。
もっと詳しく知りたい場合は、公式のチュートリアルを試してみてください。
Salesforce Lightning Design System (SLDS) を npm 経由でダウンロードし、public/assets/ 配下にコピーします。
SLDS を適用するために、views/partials/header.ejs の最下部にコードを追加します。
views/pages/db.ejs に追加すると、表示がずれてしまうので注意です。
views/pages/db.ejs のコードを修正します。長いので、コピペしてください。
表示するデータを増やすために、Heroku Postgres にテストデータを複数件インサートします。
Heroku アプリをローカルで実行します。
http://localhost:5000/db にアクセスして、画面のスタイルが変わっていることを確認しましょう。
変更前

変更後

確認が終わったら、Heroku にデプロイして終了です。
一通りの手順はわかりましたか?他の画面についても、色々試してみてください。
最終更新
役に立ちましたか?