- 관련 상품
- 2026년 8월 30일 오후 9:52 UTC
- 이름 *
- Kamo
- 뚱 베어
- eb7dae9
The "Move to folder" dialog behind the selection bar was built from a literal ['INBOX', 'Archive', 'Trash', 'Junk', 'Drafts'], so the only destinations it ever offered were the five system folders. A member who files mail into folders of their own — the whole point of having folders — could not move a selection into any of them while looking at them in the sidebar two inches to the left. Nothing failed and nothing was logged; the destination simply was not on the menu. The reported case was a "Bugs & Enhancements" folder. The dialog is now its own component and builds its list from the mailbox's folder tree, the same tree the sidebar draws, nested and searchable. Because the folder someone wants often does not exist until the moment they want it, one can be made from the dialog and moved into in a single step — leaving to go make one in the sidebar drops the selection, which is what the report asked to avoid. The vocabulary both views share — which folders are system folders, which exist whether or not the server listed them, what each is called — moves to app/lib/email/folderTargets.ts. Two copies of that list is how the picker's drifted away from the sidebar's in the first place. Two things found on the way: - The folder tree is fetched in an effect that must not depend on the translator's identity. Labelling needs `t`, and a fetch keyed on `t` refires every render the moment that identity is not stable, turning the picker into a loop against the most expensive IMAP call the product makes. The rows are derived from held raw folders instead. - `folderRefreshKey` was state nothing ever bumped. A move leaves both folders' counts wrong and a folder created here is missing from the tree entirely, so both now ask the sidebar to refetch.