Highlight of trace adds duplicate legend item.
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 25/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 停滞
- 技術スタック
- javascript, r
調査の方向性
inst/htmlwidgets/plotly.js の 733 行目と 815 行目付近にある crosstalk の選択ロジックから始めます。重複した「Alpha」の凡例エントリを再現し、選択された trace と選択されていない trace がどのように追加または暗くされるかを、issue で説明されている部分選択のケースも含めて追跡します。選択範囲が trace の一部だけを覆う場合に、ハイライトによって凡例エントリが重複せず、元の凡例が維持されれば完了です。
索引モデルが issue の本文から書いたものです。
説明
The current implementation for a selection highlighting adds duplicate legend entries.
For example in the below screenshot I clicked on trace "Alpha" and a new legend item "Alpha" got added while the existing "Alpha" legend is now dimmed but is still present. Resulting in 2 "Alpha" entries.
The core problem is that the current javascript code handling crosstalk selection, simply adds a duplicate selection traces here and dims all other traces here.
Since the original 'Alpha' trace was not removed and only dimmed and since a new trace also named "Alpha" was added to the legend. It results in the above legend.
Would it be possible to update the javascript logic to just dim the non-selected traces and update the selected trace to the desired highlight color (and other aspects set by the user). This would the have the desired effect on the legend.
Or to set the selected trace with showLegend=FALSE in the restyle for all the traces that got highlighted?
Edit it is not so easy as first thought:
I guess where my above described solution fails is when the selection is only a subset the trace data and only partially covers it. In that case the original legend entry would still need to be visible.
However, in theory it is possible to detect at creation time of the plot if the crosstalk key selection is equal to the legend entries. Eg. if the crosstalk key and the aesthetic property for the legend are equal.
That said this detection would then fail if one constructs a plotly object by manually adding traces. Or if the plotly graph has other traces added from a different dataset.
So to achieve what we want, we somehow need to determine if selection data fully covers the trace data. Not sure how we could smartly do it without having and extreme impact on the performance.
- 主要言語
- R
- スター
- 2.7k
- フォーク
- 641
- PR マージ指標
- 30日以内にマージされた PR はありません
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
plotly/plotly.R のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
-
難易度 3/5 1〜2日 初心者へのやさしさ 68/100
-
難易度 3/5 1〜2日 初心者へのやさしさ 72/100
-
save_image Error オープン
難易度 3/5 1〜2日 初心者へのやさしさ 52/100
plotly/plotly.R の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
pharmaverse/rtables#1123 · コメント 1 件 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
-
Trying to reassign a reactiveVal to the name of an existing reactiveVal doesn't overwrite the latter オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
難易度 1/5 1時間未満 初心者へのやさしさ 90/100
RConsortium/rconsortium_website#649 · コメント 2 件 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
posit-dev/r-shinylive#203 ·