enhance(frontend): 投稿フォームの設定メニューを改良

[kakkokari-gtyih]

What

• 投稿ボタン横の「リアクションの受け入れ」ボタンを消して「その他」ボタンにした
• 「その他」のポップアップ内に・・・
  • 文字数カウントを復活させた
  • 「リアクションの受け入れ」メニューを入れた
  • 投稿フォームのリセットボタンを入れた

Why

Fix #14794
Fix #10785

Additional info (optional)

Checklist

• Read the contribution guide
• Test working in a local environment
• (If needed) Add story of storybook
• (If needed) Update CHANGELOG.md
• (If possible) Add tests

[codecov]

Codecov Report

Attention: Patch coverage is 68.16143% with 213 lines in your changes missing coverage. Please review.

Project coverage is 20.06%. Comparing base (13439e0) to head (a1a0dac).

Files with missing lines	Patch %	Lines
...es/frontend/src/components/MkPostFormOtherMenu.vue	0.00%	211 Missing and 1 partial ⚠️
packages/frontend/src/components/MkMenu.item.vue	99.76%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##           develop   #14804       +/-   ##
============================================
- Coverage    40.31%   20.06%   -20.26%     
============================================
  Files         1564      731      -833     
  Lines       198083   104325    -93758     
  Branches      3837     1199     -2638     
============================================
- Hits         79863    20933    -58930     
+ Misses      117617    82839    -34778     
+ Partials       603      553       -50     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[kakkokari-gtyih]

コンフリクト解消

[kakkokari-gtyih]

コンフリクト解消

[kakkokari-gtyih]

コンフリクト解消

[kakkokari-gtyih]

コンフリクト解消

[kakkokari-gtyih]

コンフリクト解消

[kakkokari-gtyih]

コンフリクト解消

[kakkokari-gtyih]

コンフリクト解消

[syuilo]

/deploy

[syuilo]

/preview

[kakkokari-gtyih]

コンフリクト解消

[syuilo]

mkmenuと共通化すると実装のシンプルさが失われるから https://github.com/misskey-dev/misskey/blob/develop/packages/frontend/src/components/MkVisibilityPicker.vue みたいに完全オリジナルで良い気がしてきている
もし後々シンプルさを保ちつつ共通化できる実装方法が発明された場合はその時共通化できるとこは共通化するようにしても良いと思うけども

[kakkokari-gtyih]

#14804 (comment) で分けたんだけどこのやり方じゃちょっとまずかった感じかしら

[syuilo]

そーねーコンポーネントの設計に親子関係がある場合、他のコンポーネントがその子を参照するとややこしくなる気がする(子は親に隠蔽されているべき)
今回の場合、デザインとかの都合上menuとitemは親子関係であるべきだから親子関係であるという前提は崩すことが難しそう

[syuilo]

そういう前提を崩さず、かつ子を参照しない上手い共通化の方法は自分は思いつかなかった

[kakkokari-gtyih]

@syuilo MkMenuの上部にslotを設けてMkPostFormOtherMenuからMkMenuを参照させる→そのslotに文字数カウントを入れるとかどうかしら

[syuilo]

うーむアリっちゃアリだけど任意の位置に任意のコンポーネントを入れたい場合には対応できず、今回のようなたまたま入れやすい位置に入れたいものがある場合しか対応できないから完全な解決策ではないわね

あとデザインを見る感じ今回に関してはそこまで共通化するメリットなさそうだからやっぱ #14804 (comment) だと思う

[syuilo]

あーまてよ

[syuilo]

今後設定メニューに追加の項目が生まれる可能性があることを考えると共通化のメリットは大きくなってくるな

[syuilo]

うーーーーーーーーーーーーーーーーむ

[kakkokari-gtyih]

任意の位置に任意のコンポーネントを入れたい場合には対応できず

ポップアップメニューの役割上、中腹でべつのコンポーネントを入れるケースがあまり思いつかない（最上部か最下部かが主だと思う）のでそれは必要になったときに考えるので良い可能性はある
メニュー（押せる）項目を増やすならそれはMenuItemが増えるだけだし

[syuilo]

任意の位置に任意のコンポーネントを入れたい場合

例えばChromeのメニューを見るとメニューの途中で通常のitemじゃないような要素があったりする(シークレットモードのやつとかズームのやつとか)

[kakkokari-gtyih]

中腹はMenuItemに type: 'slot' 的なものを置いてスロット名を動的に定義する（ https://ja.vuejs.org/guide/components/slots#dynamic-slot-names ）ので実現しそう

type MenuSlot = {
    type: 'slot';
    name: string;
}

今回の文字数カウントはMenuの部分とは完全に分離した場所に置いているものなので少し違うかも（type: slotで対応しても良いかもだけど）

[kakkokari-gtyih]

中腹はMenuItemに type: 'slot' 的なものを置いてスロット名を動的に定義する（ https://ja.vuejs.org/guide/components/slots#dynamic-slot-names ）ので実現しそう

type MenuSlot = {
    type: 'slot';
    name: string;
}

今回の文字数カウントはMenuの部分とは完全に分離した場所に置いているものなので少し違うかも（type: slotで対応しても良いかもだけど）

あーでもこれでは os.popupMenu から直接slot入りメニューを呼び出すのは困難だわね