nextcloud-libraries / nextcloud-libraries/nextcloud-vue
[RFC] Standard size of reference widgets
Open
Nobody has claimed this yet.
1. to develop
design
feature: richtext
- Dominant language
- Vue
- Stars
- 246
- Forks
- 99
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 103
Description
Reference: https://github.com/nextcloud/spreed/issues/14506
Issue
We don't know the size of reference widget to be rendered beforehand, so it causes jumping:
- NcRichText parses the text, and detects a link -> loading starts (~30px for a spinner)
- Server can return
nullif widgets are disabled, or service is inaccessible -> render nothing (shrink to 0px) - OR it renders a simple link (~70px)
- OR it renders a link with image preview (~120px)
- OR it renders a conversation link (~220px)
- OR it renders a custom widget (any size possible)
Ideas
- Use standard size for all widgets
- Interactive wigets size should be unaffected, but non-interactive appearance should comply with the size set
- Preload information with the context (e.g Talk message object) (on app side)
- caching issues, valiation issues, request size, relying on server accessibility
- Pass height prop to
registerWidgetif custom (on app side)- always in the browser
- component doesn't know from a link, which widget would be rendered, and which size taken
- provide information (reference widget key) or parsing method to try derive richObjecType on client before actually reaching the server
- Add option to disable widgets at all (on app side)
- Not a real solution, but alternative
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading the linked spreed issue and this RFC, then inspect the NcRichText flow and the registerWidget API mentioned here. Compare the listed widget outcomes and decide on a concrete, agreed approach for preventing layout jumps. Done means a settled specification for standard sizing or another selected solution, including how custom and disabled widgets behave.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- frontend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100