С глубокой благодарностью к
@AlexGyver за то, что вдохновил на освоение HTML, Css и JS. В последние годы пишу на Python, однако алгоритмы - они везде алгоритмы. Поэтому хотел поделиться идеями, возникшими и частично воплощенными после изучения библиотеки GyverPortal и ссылок, любезно предоставленных на схожие решения.
Сперва я хотел один-в -один повторить GyverPortal на Python, так как до этого использовал собственную надстройку над EspNow, сделав одну из ESP32 графическим контроллером для визуализации процессов, а остальные - по прямому назначению управляющими и обрабатывающими события от графического контроллера, в частности. Однако наличие старых смартфонов не давало покоя и появление GyverPortal показал Путь, позволяющий уйти от собственного колхоза в пользу мобильных приложений с низким порогом вхождения.
Однако при этом я сохранил желание разделить процессы, связанные с визуализацией и обработкой событий, по этой причине препроцессинг размещения элементов html на странице, а так же логистику визуализации перенес из кода основной программы в JS (заодно начал изучение очередного языка программирования), оставив описание структуры и элементов на ESP32 и передачу ее в JSON-формате в клиентскую часть мобильника. Оговорюсь, что я сосредотачивался именно на смартфонах с тачскринами, без адаптации на планшеты и десктопы в силу своих приоритетов. Эта логика успешно использовалась в подобных библиотеках типа JeeUI 2 и ее потомках, я лишь ее реализовал, практикуясь, по ходу, в новом для себя языке JS.
Дальнейшее погружение в тему привел к мысли, что стратегия развития библиотеки может идти несколькими путями:
- расширение библиотеки виджетами и оптимизация ее кода в основной программе;
- облегчение кода основной программы за счет переноса этой нагрузки в клиентскую часть, создания метаязыка описания страниц в JSON-формате, парсинга и препроцессинга в клиентской части без необходимости подгрузки элементов html-кода и оптимизация подгрузки частей css и js библиотек;
- создания отдельной программы типа Nextion, QT-Creator или подобных им, где в графической форме рисуется визуализация и ее логика и результатом работы которой является пакет html-css-js файлов, возможно даже сжатый, который загружается на ESP и при старте основной программы перебрасывается в клиентскую часть, позволяя при разработке сосредоточится именно на обработке событий, для начала просто писать отдельную програмку, которая на основании имеющейся библиотеки готовит html, css, js файлы для загрузки на ESP32. Тоже, собственно, ничего нового - препроцессор, как это успешно применяют в ЧПУ-форматах.
Касательно событий - помимо обработки стандартных событий, генерируемых элементами html, можно устанавливать не один, а несколько таймеров в клиентской части (я пробовал устанавливать два) для обновления разных виджетов или даже принудительного перемещения по страницам путем обработки в call-back функции.
Структуру страницы можно заложить на основе css grid layout - создавая произвольную сетку и пропорции ячеек, в которые уже вписывать свои виджеты (над чем сейчас и работаю, осваивая этот css-формат) использую просто более глубокую вложенность JSON-формата при описании страниц.
Страницы реализовал трех типов - одиночная (простая), слайдер (перебор страниц стрелками, как слайдер) и бургер-меню (выбор очередной страницы из списка). Тип определяется в приложении при инициализации визуализации. Страницы, подготовленные в результате препроцессинга, живут в массиве html-страниц клиентской части, подгрузка не требуется. Так как в моем случае это мобильные приложения, то количество элементов на странице не более десятка и страницы не столь "тяжелые". Теоретически в процессе первоначального парсинга можно подключать только те части css и js, которые используются. Сейчас загружаю css и js модули в полном объеме. Сначала загружается стартовая страница, затем после ее загрузки закачиваются html-страницы, css и js библиотеки, после чего запускается основной алгоритм. Бывает немного медленнее при запуске, но не критично. Зависит, конечно, от объема визуализации.
Кстати, перенос бОльшей части визуализации и ее логики в клиентскую часть, либо препроцессорной обработке на десктопе позволяет оторваться от конкретного языка приложения (хоть на Ассемблере) и решать вопрос - синхронно или асинхронно обрабатывать поступающие события в зависимости от сложности приложения и квалификации разработчика. Хотя эмоционально формат GyverPortal-функций при описании страницы мне изначально больше понравился (кстати, это тоже можно назвать своеобразным мета-языком), чем JSON-формат. Я даже пробовал в виджет-функциях генерировать не html-код, а JSON, но это создавало дополнительную нагрузку на основной код в ESP32, что понудило отказаться от этой идеи в пользу размышлений о создании десктопного приложения по подготовке визуализации проекта (чего в одиночку не потянуть, по прошествии полугода слежения развития GyverPortal и собственного изучения css и js поймал себя на мысли, что мне для своих редких проектов проще вручную написать html-css-js, привязав к обработчику событий, но для многих, полагаю, этот путь более нерационально трудоемкий, чем использовать готовые решения с качественной поддержкой разработчика).
Это идеи, которыми решил поделиться и частично опробовал сам, что, возможно, натолкнет на мысли о стратегии дальнейшего успешного продвижения замечательного проекта GeverPortal!