) — это все теги, используемые в
, то есть почти все в целом, за исключением некоторых мета-тегов;PHP Дайджест № 222/3 (26 марта – 25 апреля 2022) / Хабр | Веб-студия Nat.od.ua
PHP Дайджест № 222/3 (26 марта – 25 апреля 2022) / Хабр
Дисклеймер: Нет, это не дайджест авторства Романа Пронского. К сожалению, у меня нет достоверной информации — будет ли выходить его дайджест далее.
Однако я взял на себя смелость временно продолжить дело Романа и написать новый дайджест за тот месяц, что прошел с выхода последнего.
Если Роман сможет и захочет далее продолжать свой дайджест — он сам решит, как использовать мой текст: взять в свой проект, как его часть или нет. На всякий случай я ставлю нумерацию дайджеста через дробь. Однако не претендуя при этом на продолжение оригинального проекта.
PHP
Вышли версии PHP:
Релизы посвящены устранению обнаруженных багов.
Кроме того:
-
Одобрен стандарт PER Coding Style, который придет на смену PSR-12
-
Запущен сайт https://thephp.foundation/ На нем можно видеть — кто в данный момент спонсирует разработку PHP и в каких объемах.
RFC (Requests for Comments )Undefined Variable Error Promotion
https://wiki.php.net/rfc/undefined_variable_error_promotion
Интересное предложение, о запрете на использование не объявленных явно переменных в PHP. Подробный рассказ о нём был в предыдущем дайджесте.
Голосование завершено, предложение принято и будет реализовано в PHP 9.
Undefined Property Error Promotion
https://wiki.php.net/rfc/undefined_property_error_promotion
Предложение, достаточно близкое к предыдущему. Внесено в начале апреля.
Предлагается в случае чтения необъявленного или не созданного явно свойства объекта выдавать ошибку уровня E_WARNING.
Идет голосование, на данный момент результат таков: 18 голосов «за» и 3 голоса «против»
Typehint Array Desctructuring
https://wiki.php.net/rfc/typehint_array_desctructuring
Свежее предложение, пока что находящееся в статусе «Черновик» и не имеющее примера реализации.
Предлагается добавить возможность контроля типов в конструкцию «разборки» массива. Например так:
$data = ;
= $data;
Предполагается, что такой контроль типов будет работать по той же схеме, что и, скажем, в аргументах функций: при установленной директиве «strict_types=0» скалярные типы будут приводиться, а при «strict_types=0» — строго проверяться.
Автор RFC надеется, что в случае принятия его предложения, будет открыт путь к типизированному присваиванию не только в случае разыменования массивов, но и для простых переменных, примерно в таком виде:
int $id = 42;True type
https://wiki.php.net/rfc/true-type
Автор предложения, George Peter Banyard, предлагает ввести в систему типов, начиная с PHP 8.2, отдельный тип true. Обосновывает, в основном, уже принятым предложением о добавлении типа false и тем фактом, что введение данного типа упростит статический анализ, и позволит улучшить работу оптимизатора.
В тексте RFC приводится такой пример:
class User {
function isAdmin(): bool
}
class Admin extends User
{
function isAdmin(): true
{
return true;
}
}
Readonly classes
https://wiki.php.net/rfc/readonly_classes
Логичное предложение, развивающее уже имеющийся синтаксис readonly-свойств на целые классы.
Цитата из RFC:
readonly class Test {
public string $prop;
}
Объект такого класса нельзя будет изменить после создания (например — переприсвоить другое значение какому-либо свойству). Попытка изменения приведет к фатальной ошибке. Дополнительно следует учесть, что в подобных классах нельзя будет объявлять статические или нетипизированные свойства.
Предложение в данный момент находится на голосовании, промежуточный итог составляет 27/6 в пользу принятия.
Новости фреймворковSymfonyРелизы
Вышли новые версии фреймворка:
Новости Symfony 6.1
В Symfony 6.1 появится возможность использования перечислений (enum) в роутах. Смотрим пример из анонса новости:
use SymfonyComponentRoutingRequirementEnumRequirement;
// ‘bar’ parameter allows all values defined in the Enum
#)]
Кроме того, добавлена возможность использовать символы UTF-8 в параметрах роутов:
use SymfonyComponentRoutingAnnotationRoute;
#
public function someControllerMethod(string $föo, string $bár)
{
// …
}
Подробнее об этих нововведениях можно прочесть по ссылке https://symfony.com/blog/new-in-symfony-6-1-improved-routing-requirements-and-utf-8-parameters
Напомню, что Symfony 6.1 находится в стадии первой беты: https://symfony.com/blog/symfony-6-1-0-beta1-released
ДругоеLaravelYii
Нет значимых новостей. См. статью на Хабре.
Новости одной строкой:
Вышла в свет библиотека AnourValar/office, предназначенная для работы с MS Excel из PHP. В частности библиотека умеет подставлять значения в шаблонные файлы и сохранять результат в разных форматах, включая PDF. Смотрите подробности на https://github.com/AnourValar/office/blob/master/README.md
Продолжает публиковаться серия статей «Functional Programming in PHP» автора Viktor Daróczi — интересный цикл, заслуживающий внимания.
Опубликована небезыинтересная видеоинструкция, посвященная настройке XDebug для Laravel в окружении Sail.
Richard Warepam пытается поставить точку в бесконечном споре на тему того, какие алгоритмы и в какой объеме должен знать каждый разработчик и предлагает свою версию «Шести алгоритмов, которые должен знать каждый»
Вышла версия PHPStan 1.6.0 Самое интересное в этом выпуске — аннотации для условных возвращаемых типов примерно такого вида:
/**
* @return ($as_float is true ? float : string)
*/
function microtime(bool $as_float): string|float
…
Опубликована интересная, но не бесспорная статья об оптимизации по памяти и времени исполнения кода при использовании генераторов.
Вместо заключения
Подготовлено при активном участии сообщества телеграм-чата «PHP Russian Talks».
Замечания по текущему выпуску и предложения для следующего можете отправлять автору в личку или в указанный выше чат.
Как правильно верстать в 2022 году. Часть 2. Как правильно вкладывать теги друг в друга | Веб-студия Nat.od.ua
Как правильно верстать в 2022 году. Часть 2. Как правильно вкладывать теги друг в друга
Привет хабр! Меня зовут Николай и я Frontend-разработчик в логистическом стартапе Relog. Хочу рассказать о самых распространённых ошибках в вёрстке современных проектов.
В этой статье мы говорим о вложении тегов друг в друга, так как это один из неочевидных моментов, в котором многие новички часто делают ошибки.
Также я расскажу о работе со спецификацией HTML — какие разделы важны для нас, как для верстальщиков и как искать там информацию.
Содержание
-
Используйте правильные теги
-
Как правильно вкладывать теги друг в друга
-
Работа с медиаконтентом
-
Пишем таблицы на HTML правильно
-
a или button? Работа с интерактивными элементами и как выбрать правильный тег
-
Различный теги для медиа-контента
-
Прекратите писать велосипеды! Как мы можем стилизовать дефолтные HTML-элементы
-
Пишем доступные формы
-
Избыточная вёрстка. Как облегчить разметку
-
Современные фишки HTML и CSS способные облегчить нам жизнь
-
Экспериментальные технологии, входящие в стандарт
Как правильно вкладывать теги друг в друга
Что значит правильно? Что является источником истины при работе с HTML? Конечно же это специфиакция! В данный момент существует так называемый «живой стандарт» пятой версии HTML. Это значит, что у него нет мажорных версий и он обновляется регулярно. Посмотреть последнее обновление спецификации можно здесь: https://html.spec.whatwg.org/
Спецификация HTML — это увесистый документ с кучей разделов. Она существует как для разработчиков браузеров, так и для нас — верстальщиков. Конкретно нас интересуют третий и четвёрный раздел (Semantics, structure, and APIs of HTML documents и The elements of HTML). Эти разделы описывают, как теги можно вкладывать друг в друга и что обозначает каждый тег.
Описание элемента
Каждый элемент имеет метаинформацию и описание.
Сверху размещены метаданные, куда включна следующая информация:
-
куда можно вкладывать тег;
-
какие теги можно вкладывать внутрь этого тега;
-
перечень аттрибутов тега (глобальные, дополнительные и ARIA);
-
информация о доступности;
-
вспомогательные данные.
Далее размещено описание тега — что он обозначает и как его можно использовать.
Спецификация элемента на примере тега
Метаданные тегаМетаданные тега
Метаинформация о теге включает в себя несколько пунктов:
-
Категории — обозначает, к каким типам тегов относится элемент, могут быть следующие типы:
-
Metadata content (например и
) — метаданные страницы, обозначающие представление или поведение содержимого, или отношение к другим документам; -
Flow content (например
, , -
Sectioning content (например
) — какие-либо большие секции, как правило имеющие конкретную структуру и заголовок; -
Heading content (все заголовки
–
, а также тег, про который я забыл рассказать в прошлой статье — ) — определяет заголовок секции, обозначенной явно, либо .
-
Phrasing content (например , , ) — различный, в основном текстовый контент, но включающий также некоторые элементы, которые позволяют размечать текст на уровне параграфов;
-
Embedded content (например
-
Interactive content (например ,
-
-
Контекст использования элемента — где мы можем размещать элемент.
-
Контентная модель — важная для этой статьи часть! Это как раз то, что мы можем размещать внутри тега.
-
Tag omission — возможные сценарии, когда закрывающую часть тега можно опустить. Рекомендую не обращать внимания на этот раздел вообще, так как в современном вебе нормальной практикой является закрытие всех парных тегов.
-
Доступные аттрибуты тега.
-
Раздел, касающийся доступности. Надеюсь когда-нибудь дойдут руки написать о работе с доступностью в рамках спецификации.
-
DOM Interface — раздел, необходимый для JavaScript-разработчиков, подробно на нём останавливаться не будем.
И всё же, как правильно вкладывать теги друг в друга?Категории элементов по HTML-спецификации
Две основные категории тегов — это Metadata (метаданные) и Flow (поточные теги). Метаданные — это то что в основном входит в
, а Flow — то что можно положить в . Однако, некоторые мета-теги мы можем разместить в , поэтому они заходят на Flow-контент (например этоJavaScript редактор текста для SVG / Хабр | Веб-студия Nat.od.ua
JavaScript редактор текста для SVG / Хабр
Demo | GitHub
<< предыдущая статья
Статья про редактор текста как на рисунке. Исходный код прилагается.
Многострочный текст в SVG
В SVG нет символа переноса строки. Для многострочного текста в SVG используется
Рис 2. Многострочный текст, третья строка пустая
Листинг 1. Многострочный текст в SVG. Третья строка пустая. Высота строки 20px.
Положение элементов
Расчетов атрибута ‘y’ можно избежать. Листинг 2 дает тот же результат. Используется атрибут ‘dy’ с фиксированным значением. ‘dy’ указывает положение относительно предыдущего элемента.
Листинг 2. Многострочный текст в SVG. Третья строка пустая. Высота строки 20px. Отступ задается относительно предыдущего элемента.
Формируем многострочную разметку на JavaScript
Функция ниже делает разметку с фиксированным атрибутом ‘dy’. Разметка получается как в листинге 2.
/**
* create multiline tspan markup
* @param {string} str
* @param {number} lineHeight
* @returns {string}
*/
function svgStrToTspan(str, lineHeight) {
return str.split(‘n’).map((t, i) => {
return `
${t.length === 0
? ‘.’
: escapeHtml(t).replaceAll(‘ ‘, ‘ ‘)}
`;
}).join(»);
}
Листинг 3. Функция делает многострочную разметку
На рисунке 1 при добавлении строки текст смещается вверх. Таким образом текст всегда по центру круга. Листинге 4 показывает как это реализовано:
/**
* @param {SVGTextElement} textEl target text element
* @param {string} str
* @param {{lineHeight:number, verticalMiddle?:number}} param
* @returns {void}
*/
export function svgTextDraw(textEl, str, param) {
textEl.innerHTML = svgStrToTspan(str, param.lineHeight);
if (param.verticalMiddle != null) {
textEl.y.baseVal.value =
param.verticalMiddle — textEl.getBBox().height / 2;
}
}
Листинг 4. Функция вставляет текст в SVG. При указании verticalMiddle текст центрируется по вертикали.
Редактор текста
Редактор должен поддерживать все стандартные возможности:
-
навигацию по тексту, выделение, вставку, копирование;
-
автозамену, проверку правописания;
-
работать на пк и мобильных.
Для стандартных возможностей есть стандартная
Алгоритм работы редактора:
-
Прозрачная
-
При вводе вызывается svgTextDraw из листинга 4;
-
Размеры и положение
пересчитываются.
Алгоритм реализован в функции textareaCreate. Код функции в отдельном файле на GitHub.
Редактор можно сделать для любого элемента
const textEditor = textareaCreate(
// {SVGTextElement}
textEl,
// text params
{ lineHeight: 20, verticalMiddle: 10 },
// init value
‘init text’,
// onchange
val => {…},
// onblur
val => {…});
…
// delete textarea
textEditor.remove();
Листинг 5. Создание редактора текста для
Другие статьи про dgrm.netКак поддержать проект
-
Начните использовать редактор блок схем Dgrm.net.
Расскажите что думаете. Любым способом: комментарии, личные сообщения, на GitHub.
Все читаю, веду список предложений. -
Расскажите знакомым.
-
Ставьте звездочки на GitHub.
Регистрозависимые ли ключи в JSON / Хабр | Веб-студия Nat.od.ua
Регистрозависимые ли ключи в JSON / Хабр
Конечно, да, скажете вы. Но не было бы этой статьи, если бы не было вопроса.
Так же эта статья будет вам полезна, если вы используете эквайринг от Тинькофф.
Немного предыстории. Какое-то время назад на одном из своих проектов я поменял онлайн-эквайринг на Тинькофф и уже после отладки начали всплывать странные ошибки с оплатой: хэш-подпись запроса считалась неверно. Причем, только на реальных платежах, что еще больше омрачало ситуацию.
Проблема оказалась в поле Data json-объекта, который приходит от банка в нотификации платежа. В одних случаях оно приходит как Data, а в других DATA (в верхнем регистре).
О проблеме я сообщил в поддержку Тинькофф и тут началось интересное. Поддержка утверждает, что регистр ключей в JSON не играет никакой роли:
Валерий, здравствуйте, JSON не является регистрозависимым. С его точки зрения DATA и Data это одно и тоже. Корень проблемы тут в вашем программном обеспечении, которое как раз регистрозависимое.
К сожалению, доказать обратное техническим специалистам Тинькофф не удалось. Найти упоминание регистрозависимости JSON в спецификации — еще более сложная задача (нашли), поэтому я поступил так, как делаю всегда: пишу код и проверяю как он работает.
Поскольку JSON сам по себе ничего не значит, а всегда обрабатывается каким-либо языком программирования, можно легко узнать, как те или иные языки относятся к ключам в разном регистре в JSON.
JavaScript — как самый популярный
Когда говорят про JSON, самым популярным языком, его использующим, является JS.
const json = JSON.parse(‘{«Data»:1,»DATA»:2}’);
console.log(json, json.Data); // {Data: 1, DATA: 2} 1
Как видим, регистр ключей играет роль. Два разных ключа с разными значениями. И если в документации указан ключ Data, то DATA не подойдет, увы.
PHP — когда нет JS
Возможно будет разница между массивом и объектом?
int 1
// ‘DATA’ => int 2
$json = json_decode(‘{«Data»:1,»DATA»:2}’, false);
var_dump($json);
// object(stdClass)
// public ‘Data’ => int 1
// public ‘DATA’ => int 2
Ситуация аналогичная. Ключи в разном регистре — это разные ключи. Преобразование в массив или в объект роли не играет.
Go — язык со строгой типизацией
Все же JS и PHP позволяют много вольностей. Возможно компилируемый язык со строгой типизацией будет вести себя иначе?
var data mapinterface{}
json.Unmarshal([]byte(«{«Data»:1,»DATA»:2}»), &data)
fmt.Println(data) // map
И снова ключи в разном регистре — это разные ключи. Мы получили map с двумя разными ключами и значениями.
C# — включаемая регистронезависимость
В комментариях выложили пример кода для C#
Поведение либо как у других языков, либо можно включить регистронезависимость и ловить ошибки при наложении свойств (хотя в случае одного свойства и правда не будет разницы).
Заключение
Если вы все еще сомневаетесь, является ли JSON регистрозависимым, просто попробуйте аналогичный код в своем языке программирования.
Я не встречал языка, в котором JSON был бы регистронезависимым. Если вы такой знаете — сообщите, будет интересно.
P.S. Я уверен, что разработчики Тинькофф тоже читают хабр. Обратите пожалуйста внимание на проблему. У вас на проде случайным образом меняется регистр ключа Data в нотификации платежа.
UPD 19.04.22 14:50
Спасибо @Busla за найденное упоминание регистрозависимости в спецификации.
Путь покупателя интернет-магазина ( Customer Journey ) с использованием УФМТП / Хабр | Веб-студия Nat.od.ua
Путь покупателя интернет-магазина ( Customer Journey ) с использованием УФМТП / Хабр
Недавно у меня вышла статья под названием «Универсальная функциональная модель торгового предприятия в нотации IDEF0». И одно из пожеланий читателей было пояснить подробнее, как я лично пользуюсь этой моделью и как вообще ее можно применять на практике. В этой статье я выполню просьбу читателей. И на примере взаимодействия покупателей с интернет-магазином продемонстрирую практическое применение этой модели.
Здесь мы будем говорить именно о покупателе интернет-магазина ( Customer Journey ), а не о потенциальном покупателе или посетителе. С точки зрения функциональной модели, это разделение я вообще не использую. Покупатель – это человек, который приходит в магазин, изучает информацию и, в конце концов, совершает покупку.
Функции покупателя
Если мы рассматриваем поведение покупателя в процессе покупки, можно выделить 4 основных функции:
-
Осознать потребность;
-
Найти товар;
-
Купить товар;
-
Получить товар.
Здесь я не стал использовать диаграмму в формате IDEF0, так как в данном случае мы не моделируем систему. Мы просто изучаем, как взаимодействует покупатель с интернет-магазином на уровне взаимодействия с моделью УФМТП.
Давайте разберемся с каждой из функций подробнее.
-
Осознать потребность
Все начинается с функции «Осознать потребность». Человек (покупатель) задумывается о том, что ему нужен определенный товар, например, сотовый телефон. Причин может быть много. Старый телефон разбит, утерян, нужен телефон в подарок кому-то или просто второй телефон для каких-либо целей. В любом случае, он осознал потребность – нужен телефон. У него появляется спрос.
Торговое предприятие при выполнении функции «Привлечь покупателя» анализирует этот спрос и формирует предложение, которое в том или ином варианте сможет увидеть покупатель. В данном случае это будет баннер в поисковой строке.
На этом этапе покупатель уже осознал, что именно ему нужно, и занимается поиском нужного товара. Например, он в поисковой строке вводит «купить телефон самсунг» и получает выдачу со ссылками на магазины, где продается нужный ему телефон.
Здесь также пересекаются две функции. У покупателя – «Найти товар», у продавца – «Привлечь покупателя», в данном случае, сделать так, чтобы объявление в поисковой выдаче человек увидел и обратил на него внимание.
В рамках этой функции человек нажимает на кнопку «Купить» в объявлении, переходит на сайт, оформляет заказ. И здесь запускаются несколько функций, которые изображены на диаграмме вв таком виде:
Возможно, у вас уже возник вопрос, почему «Продать товар» и «Доставить товар» на диаграмме выделены особо, а еще две – «Закупить товар» и «Сохранить товар» — выглядят, как второстепенные? Дело в том, что «Продать товар» и «Доставить товар» — это функции, с которыми сталкивается покупатель в рамках своей функции «Купить товар».
Таким образом, покупатель нажимает кнопку «Купить товар». В это время система проверяет наличие товара на остатках, наличие по указанной цене и так далее. После того, как функция «Продать товар» сработала, запускается функция «Доставить товар». В ее рамках товар доставляется непосредственно покупателю.
Это последняя их функций покупателя в рамках взаимодействия с интернет-магазином. Когда успешно выполняется функция «Доставить товар», покупатель должен его получить. На этом взаимодействие завершено.
Подведем итоги
Какие выводы можно сделать из этой модели:
-
Покупателя никогда не интересует, где вы закупаете товар, где вы его храните и тому подобные вещи.
-
В интернет-магазине практически не происходит взаимодействие покупателя с сотрудниками. Если у покупателя не возникает никаких вопросов, часто он вообще не звонит и никаким другим образом не общается с сотрудниками магазина. А товар получает, например, в постамате. Такое сейчас происходит очень часто.
-
Для автоматизации интернет-магазина не требуется каких-то сложных решений. Нужно, чтобы человек смог увидеть предложение, оформить заказ и получить товар.
Иногда при построении подобных моделей делают акцент на эмоциях покупателя или на необходимости получить отзыв. Это не верно. Человек становится покупателем в момент осознания потребности и перестает им быть после получения товара.
Если покупатель купил и получил товар, работа торгового предприятия считается успешной. Все подробности о том, когда он получил, как получил не имеют значения, если товар был получен в соответствии с заранее оговоренными условиями покупки.
Отзывы, конечно, получать по возможности нужно. Но это не часть взаимодействия покупатель-продавец, это, скорее, инструмент маркетинга, который поможет на этапе привлечения покупателей. Потому их получение и применение рассматривается в рамках процессов, связанных с рекламой и маркетингом.
Надеюсь, такой простой пример помог вам понять, как на практике можно использовать функциональные модели.
Меню Joomla 3 в админке Joomla 4 / Хабр | Веб-студия Nat.od.ua
Меню Joomla 3 в админке Joomla 4 / Хабр
Дисклеймер: это не полноценная статья, а небольшой «узелок на память» для тех, кому данная функция может оказаться полезной.
Многим ещё не привычна структура меню в админке Joomla 4 и поэтому появился модуль Phoca Top Menu Module. Однако, того же результата можно добиться штатными средствами и сделать структуру меню панели администратора как у Joomla 3, она становится почти такая же. Да и в принципе, к построению админки можно относиться так же, как и к шаблону сайта для фронта.
Нужно зайти в Система — Модули панели управления — Admin menu. В нём есть «Тип предустановки» меню. Включаем «Альтернативное главное меню».
Объяснение микрофронтендов / Хабр | Веб-студия Nat.od.ua
Объяснение микрофронтендов / Хабр
Я написал данный пост, так как чувствую, что Микрофронтенды это стало не просто модное слово, они уже начали распространятся на большие проекты.
Микрофронтенды могут быть следующей важной вехой в фронтенд разработке.
Давайте я вам расскажу почему!
Что такое микрофронтенды?
Микрофронтенды – это определенная структура архитектуры кода для фронтенд приложений. Все это берет начало из микросервисов на бэкенде.
Для понимания микрофронтендов и почему они нам нужны, в первую очередь нам необходимо узнать немного о них.
Микросервисная архитектура — вариант сервис-ориентированной архитектуры программного обеспечения, направленный на взаимодействие насколько это возможно небольших, слабо связанных и легко изменяемых модулей — микросервисов, получивший распространение в середине 2010-х годов в связи с развитием практик гибкой разработки и DevOps. (Википедия)
Для примера, если бы у нас был интернет-магазин с микросервисами на бэкенде, в котором за каждый сервис отвечала отдельная команда, то мы могли бы иметь следующие микросервисы:
Примечание: это упрощенный пример микросервисной архитектуры. В настоящем приложении мы могли бы иметь десятки, а то и сотни микросервисов.
В мире фронтенда, для такого типа приложения, мы могли бы разделить всё так:
Давайте отметим несколько вещей:
-
Каждый микрофронтенд может быть построен с использованием различных технологий
-
За каждый микрофронтенд может отвечать отдельная команда
-
Каждый микрофронтенд может отвечать за один микросервис
Почему стоит выбрать микрофронтенды?
Какие преимущества это может дать? На самом деле довольно много.
Помните те времена, когда вы устраиваетесь на работу, в которой разрабатывают уже старый проект, и фронт построен на XSLT и jQuery? Переписание проекта с нуля даже не рассматривается, и вам приходится использовать эти старые технологии для добавления нового функционала и исправления багов.
Если даже у вас вышло переубедить боссов начать переписывать проект, и у вас через 1-3 года появляется полностью переписанный проект. То, что мешает, через те же 10 лет, новым технологиям стать аналогом XSLT и jQuery, и морально устареть?
Микрофронтенды дают нам:
-
Маленькую, более поддерживаемую кодовую базу
-
Отдельный микрофронтенд может быть написан с выбором технологий на любой вкус – что также позволяет убрать лишние зависимости
-
За микрофронтенд может отвечать отдельная команда – позволяет убрать взаимодействие между командами, что ведет к более быстрой разработке
-
Мы можем обновить, переписать или удалить микрофронтенд когда мы посчитаем нужным
Со стороны бизнеса, правда, нужно будет взять некоторую дополнительную ответственность. Нужно будет постоянно заменять старые микро-(сервисы/фронтенды) на новые. Что позволяет постоянно улучшать свою кодовую базу.
Пример:
Мы можем удалить старый framework.X.js микрофронтенд и полностью заменить его новым framewok.Y.js. Это уменьшает необходимость переписывания, при необходимости, всего приложения с нуля.
Различные подходы
Есть несколько разных подходов в построении микрофронтендов.
Подход 1 – Один микрофронтенд на каждый микросервис
Этот вариант удобен, когда архитектура микросервисов решает отдельный проблемы. К примеру, у нас есть микросервис, который отвечает за работу с добавлением товара в корзину. И тогда мы создаем микрофронтенд, который реализует такой же функционал.
Преимущество здесь в том, что каждому микрофронтенду нужно знать всего лишь о одном бэкенд API.
Подход 2 – Компоненты
В данное время многие UI фреймворки добавляют поддержку компонентов (Svelte очень хорош в этом).
Мы можем иметь старый UI и постоянно менять старый код на компоненты. Каждый новый компонент может быть микрофронтендом написанном на Svelte, Vue, vanilla JS, или чем-либо другом на ваш выбор.
Код каждого компонента может находится на разных серверах, так что деплой может происходить без затрагивания всей системы.
Подход 3 – использование специальных инструментов для микрофронтенда
Вы можете использовать такой инструмент, как single-spa, для подключения различных микрофронтендов.
Данное решение хорошо подходит для построений новых микрофронтенд-приложений. Если вы решили использовать single-spa, то не забудьте посмотреть их документацию, а также изучить рекомендации.
Подход 4 — Module Federation
Это особенность Webpack 5, вот некоторые подробности:
Несколько отдельных сборок должны составлять единое приложение. Эти отдельные сборки не должны иметь зависимостей друг от друга, поэтому их можно разрабатывать и развертывать по отдельности. (webpack)
Есть прекрасный пост, который объясняет это.
Примечание: вы всегда можете совмещать данные подходы для достижения той архитектуры, которая вам нужна.
Нужны ли мне микрофронтенды?
Микрофронтенды точно не нужно использовать в каждой ситуации.
Микро-(фронтенды/сервисы) решают проблемы с переписыванием и расширением программного обеспечения. Также важная особенность это независимый деплой приложений.
Все зависит от того, насколько большая у вашей компании команда разработчиков. Намного легче разрабатывать, когда не все разработчики работают с одной кодовой базой, и постоянно наступают друг другу на пятки. А вместо этого, разбиты на команды, каждая из которых работает над своей группой микро-(фронтендов/сервисов).
Проблемы с микрофронтендами
Конечно, ничего не может существовать без отрицательных сторон, давайте взглянем на эти стороны у микрофронтедов:
-
Тяжелое тестирование всей кодовой базы локально, когда у вас много микро-(фронтендов/сервисов)
-
В первую очередь должен быть разработан точный интерфейс
-
Больше кода для поддержки, обновлений, а также устранений проблем безопасности
-
Затраты производительности ложатся на конечного пользователя. Так как приходится скачивать каждый микрофронтенд отдельно
-
Взаимодействие между микрофронтендами может быть довольно сложным
-
Также инфраструктура и деплой станут более сложными
Заключение
Надеюсь, что данный пост позволил Вам понять микрофронтены лучше. Спасибо за прочтение!
простое решение для создания простых сайтов / Хабр | Веб-студия Nat.od.ua
простое решение для создания простых сайтов / Хабр
Давайте признаем: современный Web стал очень сложным. Веб-дизайнеры все меньше думают о пользователях с узким каналом, которые вынуждены ждать, пока загрузится очередная огромная картинка. Иногда нам просто нужен старый добрый веб-сайт, без каких-либо дополнений, таких, как постоянное подключение к базе данных, панели администратора с WYSIWYG редактором и т. д.
Да, существует несколько способов создать веб-сайт, который будет представлять собой набор статических HTML-файлов. Но этот подход имеет массу недостатков: каждая страница загружается индивидуально, а наша задача определенно не состоит в том, чтобы возвращаться в 2000-е (хотя ностальгия может быть прекрасной, что уж там).
SPA (Single-Page Application, или одностраничное приложение) — хорошее решение, которое не требует перезагрузки каждой страницы, когда содержимое нуждается в обновлении. Но проблема в том, что эти веб-сайты полностью генерируются на стороне клиента, в браузере; не каждая поисковая система сможет их проиндексировать. В подобных ситуациях хорошим решением является рендеринг страницы на стороне сервера (Server-Side Rendering, или SSR), после этого — «переключение» в режим SPA (регидрация). Когда пользователь захочет перейти на другую страницу, с сервера будет загружен небольшой фрагмент данных, и необходимости перезагружать полностью страницу не будет.
Идея состоит в том, чтобы создать такой шаблон (boilerplate), чтобы каждый веб-мастер (или любой человек, обладающий базовыми навыками верстки на HTML и CSS) мог создать веб-сайт, который будет достаточно быстрым и удобным в обслуживании. Здесь в игру вступает Heretic.
TL;DRЧто такое Heretic?
Heretic — это что-то среднее между фреймворком и шаблоном; он позволяет вам создать очень быстрый, современный веб-сайт, сочетающий подходы SSR и SPA.
-
Heretic основан на Marko, языке, предназначенном для создания динамических и реактивных пользовательских интерфейсов
-
Используется Bulma — легкий, настраиваемый CSS-фреймворк, основанный на Flexbox
-
Используется модульная структура, весь исходный код открыт и доступен по лицензии MIT
-
Используется Webpack 5 для создания оптимизированных фрагментов, сжатых GZ, и загрузки каждой части сайта по запросу
-
Встроенная поддержка маршрутизации и интернационализации как на стороне клиента, так и на стороне сервера
-
Сочетание рендеринга на стороне сервера (SSR) и одностраничных приложений (SPA), то есть веб-сайт работает как изоморфное приложение
-
На стороне сервера используется высокопроизводительный фреймворк Fastify
Почему такое название?
В современном мире существует несколько стандартов, таких, как React и Vue. Сложность реализации быстрых и простых проектов с использованием подхода SSR, а также необходимость изучения специального синтаксиса, такого как JSX — все это значительно усложняет быструю разработку простых сайтов.
Синтаксис, используемый Marko, ничем не отличается от HTML, но при желании может предоставить массу возможностей для создания технически сложных проектов. Для использования Marko достаточно базовых знаний HTML-верстки.
Исходя из этого, появилось название, используемое проектом. Еретик – это человек, придерживающийся взглядов, идущих вразрез с общепринятыми. Так что почему бы и нет? 😉
Если вы хотите сразу посмотреть демо, то без проблем можно сделать это прямо сейчас 😉
Как начать работу?
Чтобы запустить сайт, вам понадобится веб-сервер, на котором работает Node.js. Особых требований нет, поэтому, если вы можете установить и использовать Node, вы можете хостить и веб-сайт, собранный в Heretic.
Для начала работы вам потребуется клонировать Heretic из репозитория Github:
git clone https://github.com/xtremespb/heretic.git
Затем вам нужно будет установить необходимые модули NPM:
npm i
В случае успеха необходимые модули будут загружены в директорию ./node_modules. Также потребуется создать несколько файлов, каталогов и файлов конфигурации, чтобы начать процесс сборки:
npm run setup — —defaults
Параметр —defaults необходим для создания страниц и навигации по умолчанию. Если ничего создавать не требуется, просто игнорируйте этот параметр.
Наконец, вы можете запустить процесс сборки:
npm run build-dev
Эта команда сгенерирует ваш сайт в режиме разработки (быстрее, меньше оптимизаций). Чтобы создать веб-сайт в «боевом» режиме, используйте вместо этого опцию build-production.
Наконец, запустите веб-сервер с помощью следующей команды:
npm run server
В случае успеха ваш сайт будет доступен по адресу http://127.0.0.1:3001.
Как добавить страницу?
Для добавления новой страницы на сайт необходимо выполнить следующую команду:
npm run cli — —addPage test —navigation
Данная команда создаст новую «пустую» страницу, содержащую все необходимые элементы для того, чтобы сразу начать наполнение ее контентом. В зависимости от языка, перейдите в директорию ./src/pages/test/content/lang-xx-xx (где xx-xx — код языка, например, en-us). Файл index.marko содержит контент страницы, и здесь можно использовать обычный синтаксис HTML. В случае, если потребуются дополнительные стили, в этой же директории можно создать файл style.scss (или style.css); для создания логики, основанной на JS, можно использовать файлы component.js. Подробнее о структуре компонентов Marko (а данная страница фактически представляет собой именно компонент) можно прочитать в документации по Marko.
Подробнее о доступных командах и синтаксисту конфигурационных файлов можно почитать в документации, которая, как и весь исходный код проекта, доступна на Github.
Что еще умеет Heretic?
В процессе разработки Heretic я предусмотрел большое количество нюансов, с которыми пришлось столкнуться при разработке небольших сайтов-визиток.
-
В процессе сборки автоматически генерируется файл sitemap, а также манифест для различных платформ, что позволяет не думать об этом в будущем и не прикручивать никакие «костыли»
-
Для каждой страницы можно указать не только заголовок, но и описание (description); вся информация, расположенная на странице, доступна всем движкам, которые индексируют контент и не умеют рендерить JS
-
Мультиязычный контент также отлично индексируется
-
Стилизованы страницы 404 и 500, также предусмотрена страница, отображающаяся в случае ошибок в режиме работы SPA
-
Возможность «демонизировать» сайт одной командой через PM2 и готовый конфигурационный файл для NGINX (см. подробнее в документации)
Что еще нужно сделать?
Несмотря на то, что функционал уже достаточно богат, всегда есть бесконечное пространство для улучшений. Например, доделать движок интернационализации так, чтобы он поддерживал шаблоны и плюрализацию. Написать до конца тесты. И перевести существующую локализацию «из коробки» на несколько языков (сейчас есть только русский и английский).
Не стоит забывать, что это мой пет-проект, имеющий открытый исходный код, поэтому там могут быть ошибки. Ну и разрабатывается все пару недель, поэтому многие вещи могут стать лучше. Пожалуйста, присылайте ваши идеи и Pull Request’ы.









