Это руководство по концепциям / введению предназначено для новых пользователей, которые прочитали таблицу модных слов в Основном файле Readme и хотели бы узнать больше, прежде чем следовать Руководству по началу работы.
Содержание
- Настройка рабочего
- Нет сборок Javascript (режим разработки)
- Нет строковых псевдо XML-шаблонов
- Виртуальная модель DOM на основе JSON
- Деревья компонентов на основе JSON
- Объединение деревьев компонентов и VDOM
- Что делать дальше?
Настройка рабочего
По умолчанию фреймворк использует 4 потока:
- top (Main): создание рабочих, управление реальной DOM, пересылка событий пользовательского интерфейса в приложение.
- Приложение: здесь находится большая часть фреймворка и ваших приложений.
- Данные: Ответственный за соединения BE
- Vdom: преобразование виртуальной DOM в HTML, а также расчет дельта-обновлений
Лучший способ почувствовать сотрудников - это использовать инструменты разработчика Google Chrome (консоль).
Если вы откроете приложение neo.mjs Docs App (или любое другое приложение neo.mjs), вы получите раскрывающееся меню, в котором вы можете выбрать область консоли:
Область по умолчанию (вверху) покажет (консольные) журналы внутри всех потоков.
Большинство частей фреймворка neo.mjs, а также приложений, которые вы создаете, будут работать в потоке приложения.
Подсказка. Введите Neo и нажмите Return внутри представления по умолчанию (вверху). Вы увидите части Neo, которые используются внутри основного потока. Neo.component здесь не будет. Теперь используйте раскрывающийся список и переключитесь в поток приложения. Введите Neo и снова нажмите Return. Теперь вы увидите совершенно другую версию объекта пространства имен Neo. Здесь будет существовать Neo.component, и вы можете напрямую использовать такие методы, как Neo.getComponent (‘myId’).
В чем причина использования нескольких потоков?
Как вы знаете, (почти) все компьютеры и мобильные устройства имеют несколько ядер / процессоров. По умолчанию браузеры будут использовать только один из них. Это означает, что в случае, если внутри вашего пользовательского интерфейса приложения много чего происходит, один процессор может вырасти до 100%, ваши анимации будут тормозить или ваш пользовательский интерфейс может даже зависнуть, в то время как другие процессоры простаивают. Чтобы этого не произошло, вы хотите, чтобы основной поток оставался как можно более свободным.
Процитируем Историю neo.mjs:
Если вы посмотрите страницу веб-работников в Википедии, вы найдете следующую цитату:
«Простейшее использование рабочих процессов - выполнение дорогостоящей вычислительной задачи без прерывания работы пользовательского интерфейса».
На данный момент все остальные веб-фреймворки пользовательского интерфейса все еще борются с производительностью, особенно если вы создаете большие приложения. Выполняется множество скрытых фоновых задач, которые могут замедлить вашу красивую анимацию или даже хуже: однопоточные приложения могут иметь утечки памяти, что приводит к зависанию браузера после их использования в течение некоторого времени (либо одно-единственное ядро, которое используется, работает на 100%. или использование памяти становится слишком большим).
Оглядываясь на цитату из Википедии, мы с Ричем Уотерсом пришли к выводу, что самые дорогие задачи - это фреймворк и сами приложения.
Поэтому мы задали себе вопрос:
«Что, если бы фреймворк и все создаваемые вами приложения работали бы в отдельном потоке?»
С этой идеей родился проект neo.mjs.
Резюме. Поскольку основной поток максимально простаивает, практически невозможно, чтобы ваш пользовательский интерфейс зависал или даже зависал. В случае, если много чего происходит на стороне Javascript, худшее, что может случиться, - это то, что поток приложения работает на 100%, что не повлияет на основной поток.
Нет сборок Javascript (режим разработки)
Поначалу это, вероятно, звучит по-настоящему олдскульно (до времен ES6 +):
Вы редактируете исходный файл JS, обновляете страницу и сразу получаете свои изменения. Никакого процесса (ов) сборки, никакой замены горячих модулей или чего-то еще.
Цель разработки: Отсутствие транслируемого кода Javascript, по крайней мере, для режима разработки.
В качестве примера давайте быстро взглянем на галерею в приложении Real World версии 2 (ранняя стадия, в процессе).
Это (начало) исходного кода галереи:
Full component.Gallery Source Code
Теперь давайте посмотрим на исходный код внутри браузера:
Внимательно изучите инструменты разработчика Chrome:
- Исходный код 1: 1 такой же
- Если вы посмотрите на вкладку левой консоли (Страница), вы снова увидите 4 потока. Код галереи находится внутри потока приложения.
Резюме. У цели дизайна, заключающейся в том, чтобы не переносить код Javascript (по крайней мере, на данный момент в режиме разработки), есть несколько плюсов и минусов. neo.mjs - первая инфраструктура пользовательского интерфейса, использующая JS-модули внутри воркеров, которые только что были включены в Google Chrome v80 +.
Плюсы:
- Вы получаете непревзойденный опыт отладки, так как вы можете отлаживать реальный код
(не нужны исходные карты, нет вмешательства в веб-пакеты и т. Д.) - Браузеры могут кэшировать JS-модули, и нативная упаковка находится в разработке.
- Ваша кодовая база является модульной
Минусы:
- neo.mjs не использует TypeScript (вы можете сделать это для своего собственного кода приложения, если хотите использовать процесс сборки)
- Firefox и Safari пока не поддерживают JS-модули внутри воркеров, поэтому режим разработки работает только в Chrome v80 +. Конечно, версии dist (dev и prod) также отлично работают в FF и Safari.
- Некоторые зависимости npm не могут быть легко использованы, поскольку они не используют правильный синтаксис импорта ES6 (например, отсутствующие имена файлов)
Нет строковых псевдо XML-шаблонов
Один пример с React Website:
Все видели такой код на основе шаблонов, и ... он должен исчезнуть!
К сожалению, все известные мне фреймворки все еще используют строковые шаблоны. Преимущество в том, что код выглядит как настоящий HTML и компактен.
Я думаю об этом как о сравнении XML с API на основе JSON. К настоящему времени JSON почти заменил все API, основанные на XML, и не зря.
Итак, в чем проблема со строковыми шаблонами?
Я мог бы, наверное, написать об этом небольшую книгу, но если говорить кратко:
- Не следует смешивать разметку с переменными или даже методами JS.
- Вы можете получить проблемы с областью видимости с методами, определенными внутри шаблонов
- Вся концепция определения веб-компонентов, которые затем используются в качестве строковой разметки, которая контролирует создание соответствующих экземпляров JS, ужасна (например, для их повторного использования)
- Вам необходимо проанализировать эти шаблоны, например при изменении переменной или в случае, если вы хотите сравнить два состояния компонентов, чтобы получить дельта-обновления. Это медленно!
- Честно говоря: для тривиальных компонентов это можно сделать во время сборки (например, Svelte). Однако чем сложнее становятся компоненты, тем меньше в этом смысла (слишком много вариантов, представьте neo.mjs Helix в качестве шаблона)
- Вы не можете динамически изменять структуры шаблонов, за исключением использования шаблонов Factory / Composition.
Итак, какая альтернатива?
Виртуальная модель DOM на основе JSON
Давайте посмотрим на component.Button:
_vdom: {
tag: 'button',
cn : [
{tag: 'span', cls: ['neo-button-glyph']},
{tag: 'span', cls: ['neo-button-text']}
]
}
Определение HTML-разметки через JSON (если быть точным, вложенные объекты JS и массивы) может выглядеть немного менее компактным, но преимущества очевидны: манипулировать объектами JS с помощью JS максимально просто.
Вам не нужно что-то вроде: <tpl for="listItems"><subitem></subitem></tpl>, но вы можете использовать настоящий цикл JS for.
Вам не нужно вставлять переменные в фигурные скобки.
Не нужно смешивать код разметки с методами JS.
Чтобы лучше понять идею, давайте рассмотрим более сложный пример:
component.DateSelector
При создании нового компонента вы сначала определите «скелет vdom», чтобы покрыть статические части.
Впоследствии вы можете манипулировать им или улучшать его по своему усмотрению:
Взгляните на Учебное пособие Virtual DOM & Virtual Nodes в приложении neo.mjs Docs App для получения дополнительной информации.
Деревья компонентов на основе JSON
Как и виртуальная модель DOM, деревья компонентов также основаны на JSON.
В качестве примера рассмотрим MainContainer приложения Docs.
Динамически генерировать или изменять эти деревья компонентов с помощью JS очень просто. Контейнеры также предоставляют вам некоторые удобные методы, такие как add (), insert (), remove () и т. Д. Взглянув на раздел API в приложении neo.mjs Docs App, вам поможет.
Объединение деревьев компонентов и VDOM
Поскольку оба дерева определены как JSON, вы можете легко их смешивать.
Пример: RealWorld2 App HomeContainer
Что делать дальше?
- Если вам нравятся концепции neo.mjs и вы хотели бы увидеть больше в будущем, мы приветствуем добавление звезды github в этот репозиторий.
- Взгляните на Онлайн-примеры (рабочий стол).
- Следуйте Руководству по началу работы, чтобы локально запустить фреймворк и примеры.
- Проекты с открытым исходным кодом полагаются на вашу помощь, ознакомьтесь с Руководством по участию.
- neo.mjs все еще нуждается в спонсорах для ускорения разработки: Страница спонсоров
Вы также можете найти это руководство внутри репо:
Https://github.com/neomjs/neo/blob/dev/.github/CONCEPT.md
Спасибо за чтение и отзывы,
Тобиас
