TUICPrefを書き換えたい

[kaonasi-biwa]

• updatePrefがめちゃくちゃなことになっている
• getPrefやsetPrefに型がつかない
• そもそもlocalStorageが消滅したら設定も消滅する
• 継ぎ足しに継ぎ足しを重ねたみたいな構造になっている

などからTUICPrefを書き換えたい
そしてもっとしっかりTUICPrefのIDに規則を設けたい

[kaonasi-biwa]

型付けだけを目的にしたら一応こんなコードで部分的に対応はできる(ただしエラーが出まくりそう)

function a<T extends TUICSettingIDs>(A : T | ((typeof TUICSettings)[T]["type"] extends "boolean" ? `${T}.${(typeof TUICSettings)[T]["values"][number]["id"]}` : "")
                                           | ((typeof TUICSettings)[T]["type"] extends "color" ? `${T}.${(typeof TUICSettings)[T]["values"][number]["id"]}` : "")){

}

[kaonasi-biwa]

必須の機能

• チェックボックス・リストボックス・ラジオボタン・カラーピッカーの四種の設定の書き込み/読み取り (可能であれば型もあり)
• それぞれの設定のTUICPrefからの削除 (デフォルト値に戻す)
• エクスポート・インポータント(上書き/追記)・すべての設定をデフォルトに戻す
• カスタムCSS (現在はTUICPrefと別で扱っているのでそれでも良い)

[kaonasi-biwa]

(参考程度)あったほうが嬉しい機能

• ブラウザの拡張機能のデータ保存・Ablaze Accountsによる同期
• エクスポート時にエクスポートする設定の絞り込み
• 設定画面での設定の絞り込み・設定のプレビュー
  などなど

[kaonasi-biwa]

機能とは別でやっておいたほうが良いこと

• 設定ID及びi18nの命名規則をしっかり決める
• 設定アップデートが楽にできる機構を作る

[kaonasi-biwa]

設定の引継ぎができるならどうとなっても良き

[Hibi-10000]

備考: localStorageやめて拡張機能側保存にするならFirefoxのコンテナータブに対応しないといけない

コンテナータブのAPIはこの辺を参考に
https://developer.mozilla.org/ja/docs/Mozilla/Add-ons/WebExtensions/API/contextualIdentities
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Work_with_contextual_identities
https://discourse.mozilla.org/t/firefox-container-detection-using-cookiestoreid/95050

あと拡張機能側で保存するならブラウザ側の同期があるからAblaze Accountsでの同期は優先度低いかな

[kaonasi-biwa]

ｱｧｧｧｧｧｯｧｧｧｧｧｧｧｧｧｧｯｧｧ(((((((
(まぁ選択肢は多いほうがいいですし、いきなり拡張機能側で保存できる自信もないので、最初はlocalStorageであとから切り替え可能って感じになるかなぁ...)

[kotonefami]

なんで急にお前来たんだよ

@kaonasi-biwa に呼ばれましたので意見を書いておきます

私が提案する新しい TUICPref

ベースとしては、「/src/content/modules/pref/settings.ts:TUICSettings が諸悪の根源な気がする」というのが私の意見です

注釈

正直Zodとか入れるべきなのか？と思ったけど、私がZodよくわかってないのでこの意見ではZodの利点については考えないこととします
有識者が入れたら容赦なくコメントください

設定フォーマット

まずデータ保存形式として以下のJSONフォーマットを提案します
従来の形式をすべて平坦化したようなイメージです

サンプル

{
    "colorButtonTweetUnsent": "#000000",
    "colorButtonFollow": "#000000",
    "colorButtonUnfollow": "#000000",
    "colorButtonBlock": "#000000",
    "colorButtonUnblock": "#000000",

    "tweetFooterButtons": ["reply", "retweet", "like", "share", "analytics", "bookmark"],
    "convertLikeToFavorite": true,
    "disableTweetEngagementModal": true,

    "tweetLinkCopyDomainType": "fxtwitter",
    "tweetLinkShareDomainType": "fxtwitter",

    "iconType": "twitter"
}

利点

現状、好き勝手に名前を付けまくった結果大変なことになっていて、さらにそれをカテゴリ化しようとしてオブジェクトでラップ、それをマイグレーションするためにコードが複雑化……という経緯になっていると私は考えています
そのため、まずは平坦化し、その後命名規則を整理することで簡潔かつ持続可能な設定フォーマットができるかと思います

命名規則

例えば、私は以下のように考えています
トップダウン型の命名方法を採用していますが、ここでContributorsの意見の相違が発生しそうだなとも思っています。

• iconType: 「アイコンの種類」は名詞。よってそのまま
• colorButtonBlock: 「～のボタンの色」が多すぎるので、この命名によってソート時にトップダウン型の恩恵を受ける
• disableTweetEngagementModal: 「ツイートエンゲージメント（いいね, RT, etc...）の確認モーダルを無効化する」は、名詞＋動詞。よって動詞を先に持ってきて、名詞を後に持ってくる。
• tweetFooterButtons: なんというか、そのまま。

保存方法

実際の保存についてはlocalStorageが一番良いのではないかと思いますし、Hibiさんのコメント「むやみに変えるべきではない」という意見に賛成します_{ニュアンス違ったら申し訳ないです}
単一KV形式であれば、SQLなどにも対応できるので変更も可能だと思います

設定API

では、この設定フォーマットをどう扱うかについてですが、まず同じキーで以下のようなオブジェクトを作成します。
オブジェクトであって、型ではありません。

評価の際は各自サンプルをコピーしてもらってTSサーバーがある環境に貼り付けることでいい感じに型が効いてるのを実感していただけると思います。

サンプル（設定のTS的表現）

// NOTE: Color 型については実装前にこの記事を読むことをお勧めします: https://qiita.com/manjuu_eater/items/98d5e5f66e518ed98add
type Color = `#${string}`;
type TweetFooterButtons = "reply" | "retweet" | "like" | "share" | "analytics" | "bookmark";
type LinkDomainType = "x" | "twitter" | "fxtwitter" | "vxtwitter";
type IconType = "x" | "twitter" | "dog" | "tuic" | "custom";

/** 設定の値を表現するクラス */
class PrefValue<T> {
    /** 設定の初期値 */
    public readonly defaultValue: T;
    /** 設定の値 */
    public value: T;

    public constructor(defaultValue: T) {
        this.value = defaultValue;
    }

    // NOTE: このメソッドについては後述します
    private toJSON(): T {
        return this.value;
    }
}

/** 設定オブジェクト。このオブジェクトのキーと値に従いすべての設定およびi18nを管理します。 */
const PREFERENCES = {
    "colorButtonTweetUnsent": new PrefValue<Color>("#000000"),
    "colorButtonFollow": new PrefValue<Color>("#000000"),
    "colorButtonUnfollow": new PrefValue<Color>("#000000"),
    "colorButtonBlock": new PrefValue<Color>("#000000"),
    "colorButtonUnblock": new PrefValue<Color>("#000000"),

    "tweetFooterButtons": new PrefValue<TweetFooterButtons[]>(["reply", "retweet", "like", "share"]),
    "convertLikeToFavorite": new PrefValue<boolean>(true),
    "disableTweetEngagementModal": new PrefValue<boolean>(true),

    "tweetLinkCopyDomainType": new PrefValue<LinkDomainType>("fxtwitter"),
    "tweetLinkShareDomainType": new PrefValue<LinkDomainType>("fxtwitter"),

    "iconType": new PrefValue<IconType>("twitter")
};

サンプル（設定の操作）

class TUICPref<M extends Record<string, PrefValue<any>>> {
    /** 設定値 */
    public readonly map: M;

    public constructor(map: M) {
        this.map = map;
    }

    /** 設定キーのリストを取得します。 */
    public keys(): Extract<keyof M, string> {
        return Object.keys(this.map) as any;
    }

    /** 設定を取得します。 */
    public get<K extends Extract<keyof M, string>>(key: K): M[K] {
        return this.map[key];
    }

    /** 設定します。 */
    public set<K extends Extract<keyof M, string>>(key: K, value: M[K] extends PrefValue<infer T> ? T : never): this {
        this.map[key].value = value;
        return this;
    }

    /** 設定を初期化します。 */
    public reset(): this {
        for (const [key, value] of Object.entries(this.map)) {
            this.map[key].value = this.map[key].defaultValue;
        }
        return this;
    }

    /** 同じバージョンの異なる設定を自分に上書きします。 */
    public migrate(other: TUICPref<M>): this {
        for (const key of Object.keys(this.map)) {
            this.map[key].value = other.map[key].value;
        }
        return this;
    }

    // NOTE: 命名は適当です。toJSON は内部的にしか呼ばれない（もちろん外部から呼んでもよい）のですが、対照でいい感じだと思ったので。
    /** 設定を JSON からロードします。 */
    public fromJSON(json: any): this {
        // TODO: 実装
        return this;
    }

    // NOTE: toJSON を実装しておくと、JSON.stringify を呼び出した際にここの値が利用されます。つまり、`JSON.stringify(new TUICPref())` の戻り値を生成する作業です。
    // NOTE: 先ほど PrefValue.toJSON を定義しておきましたが、あそこで定義していることによって、this.map 全体がプリミティブ型に変換可能となり、TUICPref クラスもプリミティブ型に変換可能となるのです。たぶんね。
    // NOTE: また、private としているのは外部呼び出しを想定しておらず、TUICPref.get の戻り値が {value, defaultValue} であってほしい、そのほうがきれいだからという理由です。
    private toJSON(): any {
        return this.map;
    }
}

// NOTE: 補足しておくと、この場合 PREFERENCES は定数なのに、TUICPref クラスによって値が書き換えられてしまいます。まあでも、defaultValue プロパティがあるんですから、特に問題はないですよね？
// NOTE: 2回TUICPrefをインスタンス化したい！と言われるとちょっと悩みますね。イメージですが、そうする場合はどうにかして PREFERENCES をディープクローンする必要があると思います。でも私が知る限り、そんな場面は発生していないように思えますが……。
const pref = new TUICPref(PREFERENCES);
const disableTweetEngagementModal = pref.get("disableTweetEngagementModal");
disableTweetEngagementModal.value // 今の設定の値
disableTweetEngagementModal.defaultValue // デフォルトの値

i18n

知らん。

平坦化した設定キーでも使っとけ。
ご意義あればコメントどうぞ。

マイグレーション

知らん。

ORMとか見てる限り、現代のベストプラクティスは「もう、全バージョンに対して移行コードを書くしかない……」になっていると私は推察しています。
現在と同じ手法をやっていく（ちまちま置き換えコードをずっとメンテナンスしていく）のがよいかと思います。

Tips

ここで、例えば PREFERENCES を PREFERENCES_V1 としておけば、new TUICPref(PREFERENCES_V1) と new TUICPref(PREFERENCES_V2) ができるはずです。
これを利用して、古いデータの移行も以下のように型付きでできるのではないでしょうか。

type PREFERENCES_V1 = {
    "super_bad_preference_key_for_icon_type": PrefValue<IconType>;
};

const oldPref = new TUICPref<PREFERENCES_V1>(load_preferences_v1() /* NOTE: ここの型エラーは潰すかどうにかする */);
oldPref.get("super_bad_preference_key_for_icon_type") // NOTE: 型保管が効く！しかも、type で指定しているためトランスパイル時には残らない！

const newPref = new TUICPref(PREFERENCES_V2);
newPref.set("iconType", oldPref.get("super_bad_preference_key_for_icon_type").value); // NOTE: 1行で移行！

[kaonasi-biwa]

おぉぉぉぉぉぉぉぉぉぉぉぉぉぉ！！！！！！！！！！！！！！！！！！！！！！
ありがとうございます！！！！！！！！！！！

[kaonasi-biwa]

(色に関しては背景/枠/文字がベース/ダーク/ライトで存在するような最悪9個値が存在するめちゃくちゃな状態なので、そこだけはなんとかしなければ...)

[kaonasi-biwa]

色設定に関してはどうせ色々いじりたい場所なので、最悪別Objectに分離してもいいかも

[kotonefami]

色設定に関してはどうせ色々いじりたい場所なので、最悪別Objectに分離してもいいかも

これを「ボタンの色」「非表示系」でカテゴライズした結果が今の複雑さを招いているのではないでしょうか？

個人的には、Objectへの分離に関しては反対です。
直感的な読みづらさはやはりあるかと思いますが、マイグレーション上の問題が増え、i18nキーの管理も面倒になり、設定キーリストを取得しにくくなるなどのデメリットのほうが大きいと思います。

[kotonefami]

(色に関しては背景/枠/文字がベース/ダーク/ライトで存在するような最悪9個値が存在するめちゃくちゃな状態なので、そこだけはなんとかしなければ...)

これもおすすめはしませんが、本当の本当にどうしてもカテゴライズしたい場合、 "#000000,#000000" みたいな文字列で保管するという方法はあると思います。
悪い結果にしか行かなそうな気がするので、おすすめはしませんが……

[kaonasi-biwa]

なるほどぉ…()

[kaonasi-biwa]

じゃあ9つの値もそれぞれ別のIDを割り当てた方が良いかぁ

[kaonasi-biwa]

この案で行った時の設定IDを少しずつ考えたいなぁ
ブランチ作るのがいいかしら？

[kaonasi-biwa]

それともGoogleスプレッドシートとかの方がわかりやすいかしら？

[kaonasi-biwa]

NOTE: 選択式の設定(ラジオボタン・リストボックス)においては順番を指定できる方法があったほうが良き

[kotonefami]

まあこれが最善策感あるな……

[kaonasi-biwa]

設定画面において順番が必要なやつだけなんとかしておけばこれ採用して良さそうな気はする()

[kaonasi-biwa]

色のrgb(hex)とAlphaって分けるべきだろうか？

[kaonasi-biwa]

https://developer.mozilla.org/ja/docs/Web/CSS/hex-color
HEXで同時に指定できるという衝撃の事実

[kotonefami]

色のrgb(hex)とAlphaって分けるべきだろうか？

HEXで同時に指定できるという衝撃の事実

多分自己解決してると思うけどやる必要ないんじゃないかな、とは思う

[kotonefami]

あと、ここまでIssueがでかくなるとDiscussionに場を移したほうがスレッドが長引かなくていいかも

[kaonasi-biwa]

たしかに

[kaonasi-biwa]

もうCategoryにTUICPref書き換えみたいなの追加したほうが良いかな？(無知)

[Hibi-10000]

IssueをDisccusionに変換できると思う

これか
https://docs.github.com/ja/discussions/managing-discussions-for-your-community/moderating-discussions#converting-an-issue-to-a-discussion

[kaonasi-biwa]

What!?

[kaonasi-biwa]

とりあえず雑に変えてみたのだ