そもそも「LIFF」ってどう読むのよ？で始まったLIFFを使った開発です。（”リフ”でいいのかな？）

こちら、ご存知の通り、Messaging APIの一機能として2018年リリースされています。

概要を見てもらうとわかる通り、各OSでのアプリ開発で使用するwebを表示するView機能を使って、Webアプリを提供できます。まさに気分は「LINEのトーク上でガワアプリを作って、トークルームと行ったり来たりしちゃうぞ★」。

今回の開発では、後々に検索機能が必要じゃないのかな？という判断により、トークルームへメッセージを表示してユーザー操作を誘導する形式ではなく、LIFFによるWebアプリ上でのほぼ完結する操作形式へ。

Developers向けのリファレンスにある最初のExampleを見ながら、複数ページ作ってリンク移動してみたんですが、
一番最初の初期化だけで画面の開きが待つんですね、なんとなく思った通りではありますが。
ロードで頑張っている感がするというか。（ネットワーク環境も影響するので、あくまで個人的な体感です。）
ユーザーの情報を取得できる機能があることから、何らかのユーザー認証なり、APIアクセスのための下準備が行われているはず。initメソッド内ではえいやえいやと通信しながら、内部に必要なインスタンスなりの生成をしていると考えられたので、仕方ないことなのでしょう。
が、今回の実装では、LIFF上でユーザーの操作を進める＝画面遷移がたくさんなので、「うがー！なんとかならんのか！」と悩むことになりました。

こういう時は、「世の中３人以上は同じことに悩んだ人がいるはず」という楽観思想に基づいて、世界をぐぐるのが一番です。
なんとなく、こいうしようかなという自分の考えと違う解決が見つかるかもしれないわけですし。

というわけで見つけましたー。
https://qiita.com/nori3tsu/items/306d066985697287d0d5

今回、「node.jsじゃないとダメ？ダメかな？そうですか、ダメですか。」と失敗に終わった相方との交渉により、
node.jsでのアプリ開発初挑戦でしたので、キーワードにnode.jsを入れ込むことで、参考ページをgetしました。

あーなるほどね！そうですね！SPAですね！
なんで気が付かなかったのかなーと。
参考ページを元に開発をすすめつつ、DB接続どうしようとか、logをどうとろうとか。

一番泣いたのは、うっかりアンカーで遷移すると、せっかく保持した内部データ吹っ飛ぶところですね！
（jsベースだから当たり前なんだけど）

Nuxt.jsのタグを使って遷移すると、「Cannot read property～」が開発者ツール上にされる・だが画面が表示されるときもある、という状況が発生したため、
LINE上での起こりえるかも？の不安から、通常のAタグに変えたいなと検討するも、一方で、内部データ吹っ飛ぶので、クエリパラメータで色々送らないといけないはどうかな、というジレンマ。

内部データで留めておきたいデータのTOP、実はトークルーム内でのみ有効なユーザーID。こちらを使ってメッセージ等を送ったりするわけですが、
自システム内の会員情報が持つ会員IDとMappingして、必要な時だけユーザーIDを表に出したい。
結果、最後まで頑張ってSPAで構築しました。
このユーザーIDは、LIFFの初期化時のコールバックの引数で取得できますので、今回の開発では最初の画面にて初期化して、context.userIdを利用しています。

会員情報が持つ会員IDとMappingをどのAPIを使って実装しているかについてはまた今度。