feat(text-editor): deprecate legacy image handling in favor of inlineImages#4181
Conversation
|
Warning Review limit reached
Next review available in: 48 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (3)
📝 WalkthroughWalkthroughChangesText editor deprecation documentation
Estimated code review effort: 1 (Trivial) | ~3 minutes Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Documentation has been published to https://lundalogik.github.io/lime-elements/versions/PR-4181/ |
054cce5 to
88bc9eb
Compare
| @@ -1282,7 +1282,7 @@ interface Image_2 { | |||
| } | |||
There was a problem hiding this comment.
I could be wrong, but the new functionality was only about handling images. This interface also handles links. I'm not sure if we should deprecate it yet?
There was a problem hiding this comment.
John and I talked this through. Honestly, EditorMetadata wasn't very well thought through when it first landed, and nothing at Lime Technologies actually consumes it. Since it's alpha, we're comfortable deprecating it now — and if we ever want it back, we can just un-deprecate it. We can design a proper interface for this later if a real need shows up.
On links specifically: I'm not sure consumers actually need to know when a link is pasted. If it turns out they do, a dedicated linkPasted event would probably be cleaner than folding it into metadata.
f50a4b8 to
2f59d50
Compare
|
🎉 This PR is included in version 39.44.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
The
inlineImagesprop now owns the whole inline-image lifecycle — paste, upload, storage format, and URL resolution — so the older event-based API it replaces is on the way out.Marks these as deprecated, all pointing at
inlineImages:imagePastedevent and itsImageInserterinterface (the manual paste-handling hook)metadataChangeevent and itsEditorMetadatainterfaceimageRemovedwas already deprecated; its notice pointed atmetadataChange, which is now also going away, so it's repointed atinlineImagestooNo runtime behavior changes — this is JSDoc plus the regenerated API report.
Summary by CodeRabbit
inlineImagesprop.