Проблема производительности с возможностью редактирования содержимого и выделенным блоком обратным пространством

#angular #performance #contenteditable

#angular #Производительность #contenteditable

Вопрос:

Я использую Angular 9.1.7 и contenteditable div для создания базовой возможности редактирования текста в моем приложении. Я привязал несколько обработчиков событий к этому div, но то, на что я наткнулся и что меня озадачивает, это то, что происходит, когда я выбираю абзац текста в div и набираю клавишу backspace.

ОБНОВЛЕНИЕ TL; DR Я создал минимальный воспроизводимый пример здесь, на stackblitz. Просто попробуйте удалить один из абзацев текста Lorem Ipsum, чтобы понять, что я имею в виду.

Кажется, что весь процесс браузера зависает на некоторое время (> 10 секунд). Я не могу щелкнуть по чему-либо еще, прокрутить и т. Д. Пользовательский интерфейс полностью выходит из-под моего контроля, пока внезапно это не произойдет, и эффект backspace отображается (выбранный мной блок текста удаляется). Я вставил кучу консольных журналов в некоторые обработчики событий и получил следующую последовательность событий:

 keydown
keydown
beforeinput start
beforeinput end
input start
input end
// ... out to lunch for a few seconds ...
keyup start
keyup end
  

… Я также рассчитал время начала -> окончания всех этих событий, и продолжительность их выполнения незначительна. Поэтому я не могу найти нигде в своем коде, который загружает процессор и заклинивает пользовательский интерфейс браузера. Я запустил профилировщик Chrome Dev Tools и увидел такие вещи:

введите описание изображения здесь

… и если я прокручиваю туда, где начинается начало, где начинают происходить фиолетовые вещи, я вижу это: введите описание изображения здесь

Что касается того, как Angular взаимодействует с contenteditable div, это дочерний элемент моего компонента, который выглядит так в разметке:

       <div #editableText contenteditable="true"
        (keydown)="onKeyDown($event)"
        (keyup)="onKeyUp($event)"
        (keypress)="onKeyPress($event)"
        (input)="onInput($event)"
        (beforeinput)="onBeforeInput($event)"><br></div>
  

… и я перехватываю события ввода, чтобы определить и структурировать innerHTML элемента в соответствии с моими потребностями. Это проявляется в компоненте как:

 @ViewChild('editableText', { static: false }) editableElem: ElementRef;
...
updateEditableText(html) {
  this.editableElem.nativeElement.innerHTML = html;
}
  

Я проверил, и функция updateEditableText не вызывается повторно и никоим образом не связана с проблемой производительности, насколько я могу судить.

Я не уверен, как получить больше информации о том, что здесь происходит, и я не уверен, связано ли это с обнаружением угловых изменений или с чем-то более прямым, связанным с contenteditable . Разметка в contenteditibale, лежащая в основе моего выбора для удаления, состоит из нескольких span элементов с атрибутами данных, связанными с ними, но я не могу понять, почему сложность разметки contenteditable должна иметь значение для меня, просто выбрав блок содержимого и нажав backspace.

Я ищу совета о том, как разобраться в том, что здесь происходит (например, различное использование профилировщика Chrome dev tools, методов диагностики Angular и т. Д.) И Определить источник этого узкого места в производительности, чтобы я мог либо исправить это, либо обойти проблему.

Комментарии:

1. Я вижу, что кто-то проголосовал за закрытие, я не задаю несколько вопросов, просто предоставляю достаточно подробностей и справок. Вопрос, который я задаю, заключается в том, как наилучшим образом я могу определить, что делает браузер, когда пользовательский интерфейс временно перестает отвечать на запросы.

2. Итак, что вызывает updateEditableText? Это звучит как какая-то рекурсивная вещь, может быть ..? Если вы можете воссоздать свою проблему в простом stackblitz, вероятно, было бы легче определить, что может происходить..

3. Это справедливое замечание @MikeOne, но я использую moment для временной отметки входа в эту функцию и moment для вычисления времени выполнения этой функции до выхода, и для выполнения требуется <100 мс. Я постараюсь сделать stackblitz и опубликовать здесь, если смогу.

4. @MikeOne я добавил в сообщение stackblitz

5. Хорошо, я вижу задержку — и это имеет смысл.. Вы создаете там 15 000 элементов dom… Почему перенос в <spans> ?