Germán Jabloñski

2 solutions come to mind: 1. A way to automate the serialization of any node, like this https://github.com/facebook/lexical/pull/3931 2. Add importYjs/exportYjs methods. I think solution 2 is unavoidable, since even...

Yeah. There is a similar PR with a "generic" clone that was ready to be merged but it seems the Lexical team hasn't had the time. As soon as that...

Contributing to the traceability of this discussion. In the past there have been several issues and PRs seeking to determine which properties should be excluded in yjs. For reference, see:...

Update: I correct myself again. I think ideally a decorator would actually have an `export/importYjs` method. In case it is not user defined, it could fallback to `export/importJSON`. The reason...

> # Why nested editor is not a good idea? > 1. Moving contents between editors is painful. > You can't directly move nodes between editors. Serialization is mandatory and...

> The **current** HistoryStateEntry doesn't track timestamps, and the debouncing in the **current** implementation wouldn't be able to merge entries from multiple editors. Exactly, the "current". But it is a...

Sure, but despite everything I still don't understand what problem a "DecoratorElementNode" would solve. The only problem I see is that of the undomanager, which seems obvious that it should...

As [discussed here](https://github.com/facebook/lexical/issues/4912), yjs serialization should ideally be given by `importJson` or `exportJson`. Once that's done, [the recommended way](https://lexical.dev/docs/concepts/serialization#versioning--breaking-changes) to make this backward compatible would be in the serialization methods.

You're right, my bad.

### I care a lot: - [x] Smaller ranges in "yearly income." - [ ] Work modality (fully remote, hybrid, in-person). ### I care a little: - [ ] Weekly...