Closed haushinka2dx closed 10 years ago
毎回 Local Storage から読んでいるのが気になるけど、まあいいか…。
:+1: (コードは見れていないですが)
_Complement.userUsedHistory = function(userUsedHistory) {
// キーの管理
return internalHistory(key, userUsedHistory);
}
なので、userUserdHistoryは呼び出し元から指定するのに、keyは呼び出された方が管理しているというのが違和感というか、なんか変な感じがするので
_Complement.userUsedHistory = function(key, userUsedHistory) { // keyも引数で渡す
// なんちゃらかんちゃら
return internalHistory(key, userUsedHistory);
}
このように呼び出し元でキーも気にするようにすれば userUseedHistory/groupUsedHistoryは不要になり、internalHistoryのみで事足りるのではないかという感じです。
なるほど。確かに一理ありますね。 AtmosSettings.Complement
を単なるマップ的な位置づけにすればアリな気がします。
今回のように実装したのは以下の意図(経緯)からです。
AtmosSettings
以下にまとめているAtmosSettings.Timeline
とかとは別枠のように捉えたので AtmosSettings.Complement
を新設することにしたatmos.js
側は local storage で保存してるとか local storage で使うから既にあるキーと被らないようにしないと…とかは極力関与したくない(させたくない)AtmosSettings.Complement
内で key は管理してやりたいことだけを function で提供しようuserUsedHistory
と groupUsedHistory
を愚直に実装したらキー以外はほとんど同じロジックになってしまったので、それぞれの共通ロジックを internalHistory
に抽出したinternalHistory
はキーを意識しなければならないので公開しない内部 function のままにしようという感じです。 どうですかね?
関数でキーを管理はあくまで呼び出し元では考えさせたくないということになると、 1案目の方が良いですね。 呼び出し元からしかuserUsedHistory等が作成出来ない という問題点がなければという条件付きになりますが。 (コメントへの返信ってどうやるんでしょうか。。これで出来ているのかわかりません。)
1案目の方が良いですね。
1案目って具体的にはどれでしょうか。
(コメントへの返信ってどうやるんでしょうか。。これで出来ているのかわかりません。)
コードへの返信という意味だと Add a line note というボタンを押す方で、PRについてのコメントに対する返信は…分かりませんw
修正します!
@ip-s-pra 作り替えてみました。外からは
AtmosSettings.Complement.getXXXUsedHistory()
で現在の設定を取り出しAtmosSettings.Complement.updateXXXUsedHistory(value)
で指定したキーの更新日時を現在日時でUpdate(もしくは新規登録)という感じになります。
キーも直っていていい感じかと思います。私からは特にありません!:sunny:
thanks a lot!!! 太陽いいですね。
ちなみに消す操作は出来ないので必要になったら足します。 意外とテストケースが面倒でした…。
ユーザーとグループの補完をする際に、候補を表示する際のロジックを MRU(Most Recently Used) に変えました。 簡単に言うと よく使うものが上に来る です。