chore(deps): bump @tiptap/extension-table-cell from 3.27.3 to 3.30.1 in /client

[dependabot]

Bumps @tiptap/extension-table-cell from 3.27.3 to 3.30.1.

Release notes

Sourced from @​tiptap/extension-table-cell's releases.

v3.30.1

@​tiptap/extension-table

Patch Changes

• Fixed table markdown pipe escaping so the extension loads on older Safari and iOS versions (WebKit before Safari 16.4).

@​tiptap/core

Patch Changes

• Added new ProseMirror helpers that check whether a value is a specific ProseMirror type.

v3.30.0

@​tiptap/vue-2

Minor Changes

• ceb0dac: New Decorations API

  Finally the decorations API is here! Even though Decorations itself are nothing new in ProseMirror, the new API makes it much easier to use them in Tiptap without leaving your extensions.

  Decorations change how the document looks without changing the document itself. Highlighting search results, marking spelling mistakes, showing collaborator cursors, putting a drag handle next to every block.

  Until now you had to write a ProseMirror plugin by hand for this, keep the decoration set in plugin state, and map it forward on every transaction. Extensions can now declare decorations directly with a new addDecorations() hook.

  addDecorations() {
    return {
      create: ({ state }) =>
        // findMatches can be any function that returns an array of { from, to } ranges
        findMatches(state.doc).map(match =>
          Decoration.Inline(match.from, match.to, { class: 'highlight' }),
        ),
    }
  }

  There are three kinds. Decoration.Inline() styles a range of text. Decoration.Node() puts attributes on a block's DOM element. Decoration.Widget() renders your own element at a single position.

  Every extension that declares decorations is collected into one plugin, so several extensions can decorate the same document without fighting over it.

  Doing less work on every keystroke

  By default decorations are rebuilt whenever the document changes. That is fine for small documents and wasteful for large ones, so there are two ways to narrow it down.

  shouldUpdate() skips transactions you do not care about. If your decorations only depend on headings, ignore everything else.

  update: 'changedRanges' together with createInRange() only rescans the blocks that actually changed. On a long document this is the difference between scanning the whole thing on every keystroke and scanning one paragraph.

... (truncated)

Commits

• See full diff in compare view

[Aparencia]

@dependabot rebase

[dependabot]

Superseded by #50.