Ну, доброе утро 👋

Я надеюсь, что вам понравились подвиги за последние несколько постов. Я случайно заметил, что существует множество подобных статей, в которых обсуждается ручная сборка интерфейсных фреймворков, и то, что я здесь делаю, может ничем не отличаться. При этом мне понравилось писать об этом, поэтому, если хотя бы один человек нашел это полезным/интересным, то я достаточно счастлив!

Кроме того, впоследствии мне сообщили, что я получу дерьмо БА, и что в моих пользовательских историях нет абсолютно никаких заявлений о ценности.

Так что!!

Я немного поработал над этой инфраструктурой Toy за последние пару дней и, наконец, сумел привести ее в состояние, при котором дочерняя иерархия HTMLElements может быть успешно отображена! Мой последний класс Toy выглядит так:

Просто, а??? Основная проблема, с которой я столкнулся при рендеринге дочерних элементов, заключалась в том, что каждый дочерний узел нуждался в способе рендеринга из исходного представления шаблона. Самый дешевый (см.: Наименее сложный) способ сделать это — просто аннотировать каждый дочерний узел новым свойством, называемым шаблон. Этот узел всегда будет содержать оригинальная, усатая версия HTMLElement Теперь мы можем просто заменить TextContent любого узла на его визуализированный эквивалент. Здорово!

Единственная оставшаяся сложность при таком подходе заключается в том, что всякий раз, когда заменяется текстовое содержимое, заменяется и содержимое базового узла Text. В основном это означало, что всякий раз, когда отрисовывается родительский элемент, все ожидающие изменения дочерних элементов перезаписываются.

Чтобы преодолеть это последнее препятствие, мне просто нужно было отобразить firstChild каждого узла и иметь какой-то сумасшедший рекурсивный алгоритм, чтобы гарантировать, что каждый дочерний узел каждого родительского узла является потомком и визуализируется (#descrendered).

А как же производительность, а?

Чертовски хороший вопрос. Ходят слухи, что такого рода ПРОХОЖДЕНИЕ ГРУБОЙ СИЛЫ на самом деле очень вредно для души. Не только это, но и где-то есть древний, разваливающийся ноутбук, который поспешно оживает на случай, если ему придется запускать это проклятое оправдание для производительного JavaScript где-нибудь в следующие 10 лет.

В СЛЕДУЮЩИЙ РАЗ: Давайте посмотрим, какой ущерб, я думаю? И если это действительно дерьмо, мы можем попытаться переписать что-то из этого!

На этот раз подведем довольно краткие итоги, ребята, но я хотел выделить их и подвести черту под то, что было раньше и что еще впереди!

Пока!

Первоначально опубликовано на https://blog.thesheps.dev 26 июня 2019 г.