(_transactions, oldState, newState)
| 126 | return {}; |
| 127 | }, |
| 128 | appendTransaction(_transactions, oldState, newState) { |
| 129 | if (hasContainerNode(newState.doc)) { |
| 130 | return null; |
| 131 | } |
| 132 | |
| 133 | // This is meant to deal with the weird behavior from Liveblocks's |
| 134 | // extension. It repeatedly creates transactions that do basically no |
| 135 | // changes before the actual content of the room arrives. And, if we |
| 136 | // don't do this, this plugin wraps the initial document from TipTap |
| 137 | // (an empty paragraph) with a container, and this is then kept in |
| 138 | // the TipTap, effectively duplicating containers every time someone |
| 139 | // opens the editor. |
| 140 | // |
| 141 | // This check is, at the end of the day, a heuristic and therefore it |
| 142 | // might fail. It's just not the best solution, the best solution |
| 143 | // would be for us to either not receive any content update until the |
| 144 | // contents are actually being set, or to be able to distinguish |
| 145 | // between "fake" transactions and "real" transactions in the |
| 146 | // Liveblocks extension. But, for now, this is what we have. |
| 147 | // |
| 148 | // One such case where this fails is if the email's contents are |
| 149 | // literally the default contents from TipTap, meaning an empty |
| 150 | // paragraph, it won't wrap, and we have a test for this that's being |
| 151 | // skipped in container.spec.tsx |
| 152 | if (newState.doc.eq(oldState.doc)) { |
| 153 | return null; |
| 154 | } |
| 155 | |
| 156 | return wrapInContainer(newState); |
| 157 | }, |
| 158 | }), |
| 159 | ]; |
| 160 | }, |
nothing calls this directly
no test coverage detected