0.29.1原版
This commit is contained in:
anian
@@ -0,0 +1,49 @@
|
||||
## Background & Context
|
||||
|
||||
Memos stores memo bodies as markdown, rebuilds derived memo metadata into `MemoPayload`, exposes user notifications through the inbox model, and renders memo content in the React client with custom markdown plugins. The requested `@someone` feature spans both top-level memos and memo comments: users need to type `@`, pick a valid person, render the mention inline, and notify the mentioned user. The current product already has adjacent primitives for this work: a backend markdown extension for `#tag`, an inbox-backed notification center, a generic editor suggestion popup, public user profiles under username-based routes, and a memo update path that already rebuilds payloads on create and edit.
|
||||
|
||||
External product behavior is consistent on the core interaction but different on scope. Notion supports real-time `@` suggestions inside pages, comments, and discussions, stores mention notifications in an inbox, and suppresses notification if the mentioned user cannot access the content. Confluence supports autocomplete mentions for people and teams, sends a notification on the first mention, and does not keep notifying on repeated mentions in the same page. Coda supports `@` mentions inside comment threads, treats mentions and thread participation as notification triggers, and allows broader comment-subscription settings beyond explicit mentions. These patterns suggest that the common baseline for Memos is inline autocomplete, access-aware notification, deduplication, and a clear separation between mention notifications and broader thread-subscription features.
|
||||
|
||||
## Issue Statement
|
||||
|
||||
Memos does not currently recognize `@username` tokens as structured content in memo bodies or comment bodies, does not expose any non-admin user-search endpoint that the editor can use to suggest mentionable users, does not persist or diff mention metadata during memo create or update flows, and does not have an inbox or API notification type for mentions. As a result, `@someone` currently behaves as plain text and cannot drive inline rendering, target validation, or notification delivery.
|
||||
|
||||
## Current State
|
||||
|
||||
- `server/router/api/v1/memo_service.go:32-159` creates memos by copying raw `request.Memo.Content` into `store.Memo`, enforcing length limits, and calling `memopayload.RebuildMemoPayload`; `server/router/api/v1/memo_service.go:404-510` rebuilds payload only when `content` changes during memo updates.
|
||||
- `server/router/api/v1/memo_service.go:590-681` creates memo comments by internally creating another memo and only generates inbox notifications for non-private comments to the parent memo creator via `InboxMessage_MEMO_COMMENT`.
|
||||
- `server/router/api/v1/memo_update_helpers.go:27-77` only dispatches webhook and SSE side effects after memo updates; there is no mention-diff side-effect hook.
|
||||
- `internal/markdown/markdown.go:20-24` defines extracted markdown metadata as `Tags` plus `Property`; `internal/markdown/markdown.go:68-89` only wires the custom tag extension; `internal/markdown/markdown.go:324-386` extracts tags and properties but no mention metadata.
|
||||
- `internal/markdown/extensions/tag.go:13-23` and the related tag parser/AST types are the only custom inline markdown extension path today.
|
||||
- `proto/store/memo.proto:7-29` limits `MemoPayload` to `property`, `location`, and `tags`; there is no repeated mention field or structured mention metadata.
|
||||
- `proto/store/inbox.proto:7-24` defines only `InboxMessage_MEMO_COMMENT`; `proto/api/v1/user_service.proto:592-679` defines only `UserNotification_MEMO_COMMENT`.
|
||||
- `server/router/api/v1/user_service.go:1272-1312` lists notifications by filtering inbox rows to `InboxMessage_MEMO_COMMENT` only; `server/router/api/v1/user_service.go:1433-1524` converts only that message type into API notifications.
|
||||
- `web/src/pages/Inboxes.tsx:19-114` and `web/src/components/Inbox/MemoCommentMessage.tsx` only render memo comment notifications; other notification types would currently be dropped.
|
||||
- `server/router/api/v1/user_service.go:32-70` exposes `ListUsers` only to admins, and `store/user.go:59-74` plus `store/db/sqlite/user.go:88-175` support exact-match user filtering but no general search, ranking, or pagination for mention autocomplete.
|
||||
- `server/router/api/v1/acl_config.go:20-27` whitelists `/memos.api.v1.UserService/SearchUsers`, but `proto/api/v1/user_service.proto:16-120` does not define a `SearchUsers` RPC and there is no server implementation.
|
||||
- `web/src/components/MemoEditor/Editor/index.tsx:189-214`, `web/src/components/MemoEditor/Editor/useSuggestions.ts:28-158`, and `web/src/components/MemoEditor/Editor/TagSuggestions.tsx:10-49` provide a reusable textarea suggestion popup, but it is only instantiated for `#tag`.
|
||||
- `web/src/components/MemoContent/index.tsx:53-136`, `web/src/utils/remark-plugins/remark-tag.ts:24-112`, and `web/src/components/MemoContent/Tag.tsx` parse and render `#tag` as a structured inline element; there is no `remarkMention` equivalent.
|
||||
- `web/src/hooks/useUserQueries.ts:176-245` has `useListUsers()` for admin listing and `useUsersByNames()` for fetching known usernames one by one, but nothing that returns ranked candidates for an in-editor `@` query.
|
||||
- `web/src/router/index.tsx:65-72` already routes public user profiles at `u/:username`, so inline mention rendering can target username-based profile URLs without inventing a new frontend route.
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- Adding group mentions, team mentions, page mentions, or date mentions.
|
||||
- Building a general “watch this memo/thread” subscription system beyond explicit mentions.
|
||||
- Adding email, push, Slack, or webhook delivery for mentions in this issue.
|
||||
- Redesigning memo visibility, access control, or per-user sharing semantics.
|
||||
- Making old mentions follow username changes automatically.
|
||||
- Redesigning the editor away from the current textarea-based implementation.
|
||||
|
||||
## Open Questions
|
||||
|
||||
- Which content surfaces are in scope for `@mention`? (default: top-level memos and memo comments, because both already share the same memo content pipeline)
|
||||
- What mention token syntax should be recognized? (default: `@username` only, using canonical usernames rather than display names)
|
||||
- Should edits trigger mention notifications after the initial create? (default: yes, but only for newly added mention targets compared with the memo’s previous mention set)
|
||||
- What happens if someone types `@username` in content the target cannot access? (default: render the token as a mention in the author’s view, but do not send a notification unless the target can already access the memo/comment under existing visibility rules)
|
||||
- Should mentioning yourself create an inbox item? (default: no, because self-mentions do not require attention routing)
|
||||
- Should the mention candidate API be public like `GetUser`, or authenticated like the editor? (default: authenticated only, because ranked user search is a broader directory-enumeration surface than fetching a known public profile)
|
||||
|
||||
## Scope
|
||||
|
||||
**L** — The work crosses markdown parsing, memo payload extraction, memo create/update side effects, inbox and notification protos, user search APIs, three SQL drivers, React editor autocomplete, markdown rendering, and inbox UI. The repository already contains adjacent pieces for tags and comment notifications, but `@mention` requires stitching several existing subsystems together rather than extending a single isolated module.
|
||||
@@ -0,0 +1,69 @@
|
||||
## References
|
||||
|
||||
- [Comments, mentions & reactions - Notion Help Center](https://www.notion.com/help/comments-mentions-and-reminders)
|
||||
- [Notification settings - Notion Help Center](https://www.notion.com/help/notification-settings)
|
||||
- [Mention a person or team - Confluence Cloud](https://support.atlassian.com/confluence-cloud/docs/mention-a-person-or-team/)
|
||||
- [Comment on Coda docs - Coda Help](https://help.coda.io/hc/en-us/articles/39555917053069-Comment-on-Coda-docs)
|
||||
- [Customize notifications from comments - Coda Help](https://help.coda.io/hc/en-us/articles/39555901119117-Customize-notifications-from-comments)
|
||||
|
||||
## Industry Baseline
|
||||
|
||||
`Comments, mentions & reactions - Notion Help Center` shows the most common editor-side behavior: typing `@` triggers real-time search, mentions can live inline in page bodies and comments, clicking an inbox item takes the user back to the exact context, and no notification is sent when the target cannot access the page. `Notification settings - Notion Help Center` also separates in-product inbox behavior from secondary delivery like desktop or email.
|
||||
|
||||
`Mention a person or team - Confluence Cloud` adds two useful guardrails for a collaborative editor: autocomplete suggestions appear directly from `@`, and notifications are intentionally deduplicated so people are notified on the first mention rather than on every repeated mention in the same page.
|
||||
|
||||
`Comment on Coda docs` and `Customize notifications from comments` show a narrower scope for mentions inside comments, but reinforce two patterns that matter for Memos: explicit `@` mentions are a distinct notification trigger from generic participation, and products often keep mention notifications separate from broader thread-subscription or owner-subscription rules.
|
||||
|
||||
Across these products, the default implementation is not “parse arbitrary display text and hope it matches a user.” The stable interaction is: search among valid workspace members, insert a canonical mention token, render it differently from plain text, and only notify when access and deduplication rules say the event is meaningful.
|
||||
|
||||
## Research Summary
|
||||
|
||||
Memos already has the right extension points to adopt that baseline without a storage redesign. The backend has a custom inline markdown extension pipeline for `#tag`, memo create and update both rebuild `MemoPayload`, and the inbox model already represents user-facing attention items. The frontend editor already has a trigger-character suggestion popup, the markdown renderer already recognizes custom inline nodes, and public user profiles are already routed by username.
|
||||
|
||||
The biggest mismatch is user discovery. The current `ListUsers` path is admin-only and exact-match oriented, while mention autocomplete needs a normal authenticated user search API that can return ranked candidates by username and display name. The second mismatch is notification shape: the inbox and API layers only understand memo-comment notifications today, so a mention feature cannot be expressed as a first-class notification without extending the inbox proto and inbox UI.
|
||||
|
||||
Research also suggests that Memos should stay narrower than Notion or Confluence. There is no existing concept of teams, group mentions, page mentions, or per-page ACLs. The codebase already treats usernames as the public user token and memo visibility as a coarse `PUBLIC/PROTECTED/PRIVATE` rule. The best fit is therefore person mentions only, keyed by canonical username, with notification rules that are access-aware and deduplicated across repeated edits.
|
||||
|
||||
## Design Goals
|
||||
|
||||
- Typing `@` in the memo editor or comment editor shows ranked, authenticated user candidates and inserts a canonical `@username` token on selection.
|
||||
- The backend extracts mention targets from memo/comment content during create, update, and payload rebuild, and produces the same mention set for equivalent content across all supported databases.
|
||||
- Mention notifications are created only for newly added targets, at most once per target per memo revision, and never for self-mentions or inaccessible private content.
|
||||
- Memo content renders resolved mentions as interactive inline entities and degrades unresolved tokens to plain text.
|
||||
- The inbox API and inbox UI expose mention notifications as a first-class type distinct from comment notifications.
|
||||
- The design does not require a relational schema migration; it only extends existing proto-backed JSON payloads and server/frontend code paths.
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- Adding group mentions, team mentions, page mentions, or date mentions.
|
||||
- Building a generic watch/subscription system for memo activity.
|
||||
- Sending mention notifications through email, push, Slack, or webhooks.
|
||||
- Making mention references survive username changes automatically.
|
||||
- Replacing the textarea editor with a richer block editor.
|
||||
- Redesigning memo visibility or introducing user-level memo sharing.
|
||||
|
||||
## Proposed Design
|
||||
|
||||
Support only canonical `@username` mentions in this issue. The parser should recognize the same username token vocabulary that the API already accepts for public user names, instead of trying to match display names or arbitrary free text. This keeps mention authoring aligned with existing user resource naming and avoids ambiguous matches when multiple users share similar display names. Mention suggestions may show both display name and username, but the inserted source text remains `@username`.
|
||||
|
||||
Add a backend markdown mention extension parallel to the existing tag extension. Introduce `internal/markdown/ast.MentionNode`, `internal/markdown/parser.NewMentionParser()`, and `internal/markdown/extensions.MentionExtension`, then wire it into `internal/markdown/markdown.go` next to `TagExtension`. The mention parser should require a word boundary before `@` so email addresses and URLs do not become mentions, and it should normalize the captured token to lowercase before lookup because usernames are canonicalized that way in the API layer.
|
||||
|
||||
Extend `storepb.MemoPayload` with a repeated mention metadata field, for example `repeated Mention mentions`, where each item stores at least `username` and resolved `user_id`. The raw markdown remains the source of truth for author-visible text, but the payload becomes the normalized server-side mention set for diffing and notification decisions. This reuses the existing memo payload rebuild path and avoids reparsing memo bodies in multiple side-effect handlers. No SQL migration is required because memo payloads are already stored as proto-backed JSON blobs in each database driver.
|
||||
|
||||
Teach `memopayload.RebuildMemoPayload` to resolve mention metadata while rebuilding tags and properties. The extraction step should walk the markdown AST once, collect raw `@username` tokens, resolve them to active users via the store, deduplicate by `user_id`, and populate `memo.Payload.Mentions`. Unresolved usernames should not fail memo creation; they should simply be omitted from normalized mention metadata so the feature remains tolerant of free-typed text. This mirrors how the frontend can degrade unresolved tokens back to plain text.
|
||||
|
||||
Add a dedicated mention side-effect helper around memo create and update flows. On create, after the memo is persisted and the final payload is available, compute the normalized mentioned user set from `memo.Payload.Mentions` and create inbox items for allowed targets. On update, diff the previous and new normalized mention sets and only notify targets that were newly added in the latest saved revision. This follows the Confluence-style deduplication pattern and prevents repeated notifications when a memo is edited without changing its mention set. If a mention is removed and later re-added, it counts as newly added again and may generate a fresh inbox item.
|
||||
|
||||
Apply access and duplication rules before writing inbox rows. Self-mentions are ignored. For top-level memos, notify only when the target can already read the memo under current visibility rules. For comments, notify the mentioned user when they can read the comment context and are not already covered by the existing memo-comment notification to the parent memo owner for that same event. This keeps mention notifications meaningful and avoids sending an owner both a comment notification and a mention notification for the same comment creation unless future product requirements explicitly want both. For `PRIVATE` memos and `PRIVATE` comments, mentions remain author-visible text but do not generate inbox notifications for other users.
|
||||
|
||||
Extend inbox storage and API notifications with a dedicated mention type instead of overloading the existing comment type. Add `MEMO_MENTION` to `proto/store/inbox.proto` with a payload that can represent both top-level memos and comments, such as `memo_id` plus optional `related_memo_id`. Mirror that in `proto/api/v1/user_service.proto` with `UserNotification_MEMO_MENTION` and `MemoMentionPayload`. Reuse the current notification conversion pattern in `server/router/api/v1/user_service.go`: resolve memo names from stored IDs, return a first-class mention payload, and let the inbox page render a separate mention card component. This keeps the notification center composable as new activity types appear.
|
||||
|
||||
Add an authenticated user-search endpoint specifically for mention autocomplete. The repository already has a stale public-method placeholder for `SearchUsers`, but no proto or handler. Define `SearchUsers` in `proto/api/v1/user_service.proto`, remove it from the public ACL list, and implement it in `server/router/api/v1/user_service.go` as an authenticated RPC that accepts a short query string plus page size. Extend `store.FindUser` with search-oriented fields and implement driver-specific case-insensitive matching in SQLite, MySQL, and PostgreSQL over `username` and `nickname`, ordered by exact username match, username prefix, nickname prefix, then a stable fallback. This produces a usable editor candidate list without reusing the admin-only `ListUsers` contract.
|
||||
|
||||
Implement frontend mention suggestions by reusing the existing generic textarea suggestion system. Add a `MentionSuggestions` component beside `TagSuggestions`, hook it into `web/src/components/MemoEditor/Editor/index.tsx`, and back it with a debounced `useSearchUsers(query)` hook. The popup should render avatar, display name, and `@username`, while selection inserts `@username ` exactly. Because `useSuggestions` currently operates on local item arrays, it can stay generic if the mention hook owns the remote query and passes the current ranked results down as `items`.
|
||||
|
||||
Implement frontend mention rendering with a dedicated markdown plugin and component instead of trying to infer mentions from links or plain spans. Add `remarkMention` beside `remarkTag`, a `Mention` inline component beside `Tag`, and a mention type guard in `web/src/types/markdown.ts`. The renderer should link resolved mentions to `/u/:username`, show display name or username with avatar-based affordance when lookup data is available, and render unresolved mention text non-interactively. To avoid N-per-mention network fetches, `MemoContent` should collect mentioned usernames from content and hydrate them through the existing `useUsersByNames()` hook once per memo render tree.
|
||||
|
||||
Render mention notifications as their own inbox card. Reuse the existing `MemoCommentMessage` pattern, but resolve the source memo/comment and optional related memo from the `MemoMentionPayload`. The card should show who mentioned the user, in what memo or comment, a short snippet, and navigate to the relevant memo detail on click. `web/src/pages/Inboxes.tsx` should switch on both `MEMO_COMMENT` and `MEMO_MENTION` so the inbox can grow by type without silently discarding new notifications.
|
||||
|
||||
Do not solve username drift in this issue. If a user later changes username, existing raw markdown still contains the old `@username` text, and rebuilt payload metadata will stop resolving unless the old token still matches a live username. This is acceptable for the current scope because username-history and alias resolution are already out of scope elsewhere in the codebase. The alternative of storing opaque mention IDs in source markdown or adding a username-alias subsystem was rejected because it turns a contained collaboration feature into a broader identity migration project.
|
||||
@@ -0,0 +1,37 @@
|
||||
## Execution Log
|
||||
|
||||
### T1: Add backend mention parsing and payload extraction
|
||||
|
||||
**Status**: Completed
|
||||
**Files Changed**: `internal/markdown/ast/mention.go`, `internal/markdown/parser/mention.go`, `internal/markdown/extensions/mention.go`, `internal/markdown/markdown.go`, `internal/markdown/renderer/markdown_renderer.go`, `server/runner/memopayload/runner.go`, `server/router/api/v1/memo_service.go`, `server/router/api/v1/v1.go`, `server/router/api/v1/test/test_helper.go`, `internal/markdown/markdown_test.go`
|
||||
**Validation**: `go test ./internal/markdown` — PASS
|
||||
**Path Corrections**: `RebuildMemoPayload` needed `context + store` so mention resolution could happen during payload rebuild.
|
||||
**Deviations**: None
|
||||
|
||||
### T2: Add mention notifications and user search APIs
|
||||
|
||||
**Status**: Completed
|
||||
**Files Changed**: `proto/store/memo.proto`, `proto/store/inbox.proto`, `proto/api/v1/user_service.proto`, `server/router/api/v1/user_service.go`, `server/router/api/v1/connect_services.go`, `server/router/api/v1/acl_config.go`, `server/router/api/v1/acl_config_test.go`, `server/router/api/v1/memo_mention_helpers.go`, `store/user.go`, `store/db/sqlite/user.go`, `store/db/postgres/user.go`, `store/db/mysql/user.go`, `server/router/api/v1/test/user_notification_test.go`, `server/router/api/v1/test/user_search_test.go`
|
||||
**Validation**: `go test ./server/router/api/v1/...` — PASS
|
||||
**Path Corrections**: Unknown legacy inbox message types are filtered server-side to keep unread counts aligned with rendered cards.
|
||||
**Deviations**: None
|
||||
|
||||
### T3: Add frontend mention autocomplete, rendering, and inbox UI
|
||||
|
||||
**Status**: Completed
|
||||
**Files Changed**: `web/src/components/MemoEditor/Editor/MentionSuggestions.tsx`, `web/src/components/MemoEditor/Editor/index.tsx`, `web/src/components/MemoEditor/Editor/useSuggestions.ts`, `web/src/hooks/useUserQueries.ts`, `web/src/utils/remark-plugins/remark-mention.ts`, `web/src/components/MemoContent/MentionContext.tsx`, `web/src/components/MemoContent/Mention.tsx`, `web/src/components/MemoContent/index.tsx`, `web/src/components/MemoContent/ConditionalComponent.tsx`, `web/src/types/markdown.ts`, `web/src/components/Inbox/MemoMentionMessage.tsx`, `web/src/pages/Inboxes.tsx`
|
||||
**Validation**: `pnpm lint && pnpm build` — PASS
|
||||
**Path Corrections**: Editor autocomplete reused the existing generic suggestion hook by exposing the live query rather than duplicating keyboard navigation logic.
|
||||
**Deviations**: None
|
||||
|
||||
### T4: Regenerate code and validate the feature
|
||||
|
||||
**Status**: Completed
|
||||
**Files Changed**: `proto/gen/**`, `web/src/types/proto/**`
|
||||
**Validation**: `buf generate` — PASS; `go test ./internal/markdown ./server/router/api/v1/...` — PASS; `pnpm lint` — PASS; `pnpm build` — PASS
|
||||
**Path Corrections**: None
|
||||
**Deviations**: None
|
||||
|
||||
## Completion Declaration
|
||||
|
||||
All tasks completed successfully
|
||||
@@ -0,0 +1,104 @@
|
||||
## Task List
|
||||
|
||||
### Task Index
|
||||
|
||||
T1: Add backend mention parsing and payload extraction [M] — T2: Add mention notifications and user search APIs [L] — T3: Add frontend mention autocomplete, rendering, and inbox UI [L] — T4: Regenerate code and validate the feature [M]
|
||||
|
||||
### T1: Add backend mention parsing and payload extraction [M]
|
||||
|
||||
**Objective**: Parse `@username` tokens into structured mention metadata during memo payload rebuilds.
|
||||
**Size**: M
|
||||
**Files**:
|
||||
- Create: `internal/markdown/ast/mention.go`
|
||||
- Create: `internal/markdown/parser/mention.go`
|
||||
- Create: `internal/markdown/extensions/mention.go`
|
||||
- Modify: `internal/markdown/markdown.go`
|
||||
- Modify: `internal/markdown/renderer/markdown_renderer.go`
|
||||
- Modify: `server/runner/memopayload/runner.go`
|
||||
- Modify: `server/router/api/v1/memo_service.go`
|
||||
- Test: `internal/markdown/markdown_test.go`
|
||||
**Implementation**:
|
||||
1. Add mention AST/parser/extension parallel to the existing tag implementation.
|
||||
2. Extend extracted markdown data and `MemoPayload` rebuild to collect normalized mentions and resolve them to users.
|
||||
3. Update memo create/update and background payload rebuild paths to use the new mention-aware payload builder.
|
||||
**Boundaries**: Do not add a relational schema migration.
|
||||
**Dependencies**: None
|
||||
**Expected Outcome**: Memo payloads carry normalized mention metadata rebuilt from markdown content.
|
||||
**Validation**: `go test ./internal/markdown` — expected `ok`
|
||||
|
||||
### T2: Add mention notifications and user search APIs [L]
|
||||
|
||||
**Objective**: Expose mention-aware APIs and create inbox items for newly added mentions.
|
||||
**Size**: L
|
||||
**Files**:
|
||||
- Modify: `proto/store/memo.proto`
|
||||
- Modify: `proto/store/inbox.proto`
|
||||
- Modify: `proto/api/v1/user_service.proto`
|
||||
- Modify: `server/router/api/v1/user_service.go`
|
||||
- Modify: `server/router/api/v1/connect_services.go`
|
||||
- Modify: `server/router/api/v1/acl_config.go`
|
||||
- Modify: `server/router/api/v1/acl_config_test.go`
|
||||
- Create: `server/router/api/v1/memo_mention_helpers.go`
|
||||
- Modify: `store/user.go`
|
||||
- Modify: `store/db/sqlite/user.go`
|
||||
- Modify: `store/db/postgres/user.go`
|
||||
- Modify: `store/db/mysql/user.go`
|
||||
- Test: `server/router/api/v1/test/user_notification_test.go`
|
||||
- Test: `server/router/api/v1/test/user_search_test.go`
|
||||
**Implementation**:
|
||||
1. Extend proto contracts with `MemoPayload.mentions`, `InboxMessage.MEMO_MENTION`, `UserNotification.MEMO_MENTION`, and `SearchUsers`.
|
||||
2. Implement authenticated user search over username and nickname.
|
||||
3. Add mention notification side effects for memo create/update/comment flows with diffing and duplicate suppression.
|
||||
4. Convert inbox rows into either comment or mention notifications and filter unknown legacy types.
|
||||
**Boundaries**: Do not add email/push/webhook mention delivery.
|
||||
**Dependencies**: T1
|
||||
**Expected Outcome**: Mentioned users receive inbox notifications and the editor has an API to fetch mention candidates.
|
||||
**Validation**: `go test ./server/router/api/v1/...` — expected `ok`
|
||||
|
||||
### T3: Add frontend mention autocomplete, rendering, and inbox UI [L]
|
||||
|
||||
**Objective**: Let users insert mentions from the editor and render/read them in the UI.
|
||||
**Size**: L
|
||||
**Files**:
|
||||
- Create: `web/src/components/MemoEditor/Editor/MentionSuggestions.tsx`
|
||||
- Modify: `web/src/components/MemoEditor/Editor/index.tsx`
|
||||
- Modify: `web/src/components/MemoEditor/Editor/useSuggestions.ts`
|
||||
- Modify: `web/src/hooks/useUserQueries.ts`
|
||||
- Create: `web/src/utils/remark-plugins/remark-mention.ts`
|
||||
- Create: `web/src/components/MemoContent/MentionContext.tsx`
|
||||
- Create: `web/src/components/MemoContent/Mention.tsx`
|
||||
- Modify: `web/src/components/MemoContent/index.tsx`
|
||||
- Modify: `web/src/components/MemoContent/ConditionalComponent.tsx`
|
||||
- Modify: `web/src/types/markdown.ts`
|
||||
- Create: `web/src/components/Inbox/MemoMentionMessage.tsx`
|
||||
- Modify: `web/src/pages/Inboxes.tsx`
|
||||
**Implementation**:
|
||||
1. Add `@` autocomplete backed by `SearchUsers`.
|
||||
2. Add markdown mention parsing/rendering and hydrate mentioned users once per memo render.
|
||||
3. Add a dedicated inbox card for memo mention notifications.
|
||||
**Boundaries**: Do not redesign the textarea editor.
|
||||
**Dependencies**: T2
|
||||
**Expected Outcome**: Users can insert, see, and open mentions from memo content and inbox notifications.
|
||||
**Validation**: `pnpm lint && pnpm build` — expected success
|
||||
|
||||
### T4: Regenerate code and validate the feature [M]
|
||||
|
||||
**Objective**: Regenerate generated code and verify backend/frontend behavior.
|
||||
**Size**: M
|
||||
**Files**:
|
||||
- Modify: `proto/gen/**`
|
||||
- Modify: `web/src/types/proto/**`
|
||||
**Implementation**:
|
||||
1. Run `buf generate` after proto changes.
|
||||
2. Re-run focused Go tests and frontend lint/build.
|
||||
**Boundaries**: Do not broaden into unrelated CI cleanup.
|
||||
**Dependencies**: T1, T2, T3
|
||||
**Expected Outcome**: Generated code matches the new APIs and validations pass.
|
||||
**Validation**: `buf generate`, `go test ./internal/markdown ./server/router/api/v1/...`, `pnpm lint`, `pnpm build`
|
||||
|
||||
## Out-of-Scope Tasks
|
||||
|
||||
- Group/team mentions
|
||||
- Username alias migration
|
||||
- Email or push delivery for mentions
|
||||
- Watch/subscription semantics beyond explicit mentions
|
||||
Reference in New Issue
Block a user