vue-cliからの開発メモ

vue-cliを使ってアプリを開発しているが、これ色々とテクニックを忘れそうなので、セットアップやフレーム作った時に行ったことのメモをする。

はじめに

vue-cliは、Nodejs製のVueプロジェクトテンプレートを自動生成するツール。初めから色々なものが組み込まれている。

  • webpack（バンドラ。jsやcssや画像が100個に分かれてブラウザがロードにムキイイ！！ってなるところを黒魔術で１つのJavaScriptにしてダウンロード後展開するようにしてくれるツール）
  • ESLint（静的解析。ちょっとでもお作法に触れるとビシィ！ってErrorを出す心なきセンセイ）
  • 有名なunitテストフレームワーク（単体テスト）
  • 有名なe2eテスト（End to Endテスト。ヘッドレスブラウザとか使って画面操作相当のことを自動テスト）
  • ローカル開発で利用する簡易Webサーバー付き（ヤバイ）

使ってみた感じ、このフレームワーク使う？ってかんじでCLIベースで打ち込むだけであら不思議、modernなプロジェクトが出来上がっちゃう。

インストール～初回動作確認

Nodejsとvue-cliのインストール

まずはNodejsをインストール。ここらは下記にまかせる

https://nodejs.org/en/#download

それから下記に従って、vue-cliを導入

https://cli.vuejs.org/guide/installation.html

プロジェクト作成

これまた公式ドキュメントの力を借りる

https://cli.vuejs.org/guide/creating-a-project.html

開発サーバー起動

プロジェクトのルート（package.jsonが配置している）にコンソールで入って下記

npm run dev

これでESLint + コンパイル + Webpack + 開発用WebServerが http://localhost:8080 に立ち上がる。 以降、srcのコンテンツを更新するごとに自動で差分コンパイルが走って上記に反映される。

（ちなみに、このときのNODE_EVNのデフォルト値=development）

色々改良

webpackのloaderを導入

例えばVueの <style lang="scss"> 使いたいなーってとき

  1. プロジェクトのnode_moduleにwebpackのloaderを導入

プロジェクトルートにコンソールで立って

npm install sass-loader node-sass --save-dev
  1. loaderに渡すconfigを変更

多分ここはvue-loaderのバージョンによって変わる。2.9.6だと、色んな依存関係の先に下記だった

/(path to project)/build/util.js

設定内容については下記参照

http://system.blog.uuum.jp/entry/2018/01/10/110000

各ローダーに対して共通のファイルをロードさせる

/(path to project)/build/util.js

設定内容については下記参照

http://system.blog.uuum.jp/entry/2018/01/10/110000

参考文献

https://qiita.com/567000/items/dde495d6a8ad1c25fa43

http://system.blog.uuum.jp/entry/2018/01/10/110000

非同期処理の悩みどころ

「UI向上のために非同期をしなければいけないんだ！！！！！！！」が界隈世間一般の語彙になって10年ぐらいだろうか、今初めてUIで簡単な非同期処理を実装してみてマルチスレッドは難しい問題を身に染みている。

タスクの取り消しは正常系

検索をかけた、でも結果が返ってこない。おそらくユーザーはキャンセルするだろう。 その挙動は、キャンセル可能であれば望ましい。

夜間に更新して日中は一切更新しないデータベースを参照するだけのアプリであれば何も考えずThreadにabort要求を投げて、また新しく検索しなおせば同じ結果になるが、 更新と参照が入り乱れる業務アプリや、動的にキャッシュを作成してやりくりする涙ぐましいリソースの切り盛りをしている基盤は、abortできる処理とできない処理を切り分けないといけないし、恐らくそれは、心地の良いUIを作るうえで障害となる。

ぱっと考えた対策

1. トランザクションのACID特性の強化

更新処理は、abortできるものにする。 例えば「法人を消したら、それに紐づく顧客情報すべても無効とする」という少なくも２テーブルを更新する処理をする際、 処理が中途半端にabortしたら「法人はつぶしたけど、顧客は生きている」などの更新不整合が発生しないようにする。

HTTP <-> client なアプリでは導入しやすいが、WindowsアプリやJavaScriptなメモリを書き換える環境では、グローバルな参照オブジェクトへのCommitタイミングを意図的に調整する工夫がいる。

2. 関連する処理を直列キューにする

顧客情報を更新・参照する処理は顧客情報関連の直列キューなど、処理の順序を保証する。 サバクラだと性能が死ぬが、クライアント内で実装する分には、GUIのロックを下げるだけの効果はある。（どうせ処理待ちは発生するので、ユーザーの自由度を少しでも上げる）

Redshiftでクエリの処理時間を計測する

SQL

-- セッション中、結果キャッシュを切る
-- コンマ数秒で結果が返ってくることはなくなるが、
-- 同じようなレコードを取得するクエリを連続で実行すると、
-- コンピューティングノードで直近ディスクロードした内容が
-- オンメモリになってキャッシュされているか何かで
-- 読み込みが倍以上に早くなり正確に計測できなくなる。
set enable_result_cache_for_session TO off;

-- トランザクション開始
begin;

-- 何かクエリ
select * from pg_user;

-- クエリID指定で、直前のクエリのWLMのクエリ処理ログ確認。トランザクション切っていると、新しく出たのは自トランザクションで切ったものしか見えない。
SELECT userid, xid, query, total_queue_time, exec_end_time FROM stl_wlm_query WHERE query = PG_LAST_QUERY_ID();