Хочу представить фреймворк для написания микрофронтеднов с поддержкой Webpack Module Federation. Фреймворк позволяет связывать приложения написанные на любых библиотеках, ванильном JS, и даже IFrame, если дела совсем плохи.

Недавно была статья, где довольно подробно было расписано, что есть на рынке. Однако большинство решений навязывают некие дополнительные концепции, будь то раутинг или реестр приложений, хотя по факту иногда ничего из этого не нужно, а нужен лишь простой и легкий способ внедрить одно приложение в другое.

Эта статья — попытка свести воедино имеющиеся на текущий момент средства и выяснить, возможно ли создавать production ready приложения на React без предварительной компиляции сборщиками типа Webpack, или по крайней мере свести такую компиляцию к минимуму.

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

Возможность использовать ECMAScript modules (<script type="module"/> с импортами вида import Foo from './foo'; и import('./Foo')) прямо в браузере давно не новость, это хорошо поддерживаемы функционал: https://caniuse.com/#feat=es6-module.

Но в реальности мы импортируем не только свои модули, но и библиотеки. Есть отличная статья на эту тему: https://salomvary.com/es6-modules-in-browsers.html. И другая не менее хорошая статья достойная упоминания https://github.com/stken2050/esm-bundlerless.

Среди прочих важных вещей из этих статей, эти пункты наиболее важны для создания React приложения:

• Поддержка package specifier imports (или import maps): когда мы пишем import React from 'react' на самом деле мы должны импортировать что-то подобное https://cdn.com/react/react.production.js
• Поддержка UMD: React до сих пор распространяется как UMD и на данный момент авторы все еще не пришли к согласию как распространять библиотеку в виде модуля
• JSX
• Импорт CSS

Давайте пройдем по всем пунктам по очереди.

Из комментариев к статье стало понятно, что очень многие люди склоняются в сторону экосистемы Create React App (он же React Scripts). Это вполне разумно, т.к. это самый популярный и простой в использовании продукт (благодаря отсутствию конфигурации и поддержке ведущих людей React-сообщества), в котором, к тому же, есть почти все необходимое — сборка, режим разработки, тесты, статистика покрытия. Не хватает только серверного рендеринга.

В качестве одного из способов в официальной документации предлагается либо вбивать начальные данные в шаблон либо воспользоваться статическими слепками. Первый подход не позволит поисковикам нормально индексировать статичный HTML, а второй — не поддерживает проброс никаких начальных данных, кроме HTML (фраза из документации: this doesn't pass down any state except what's contained in the markup). Поэтому если используется Redux, то придется для рендеринга использовать что-то другое.

Я адаптировал пример из статьи для использования с Create React App, теперь он называется Create React Server и умеет запускать серверный рендеринг командой:

create-react-server --createRoutes src/routes.js --createStore src/store.js

Каждый раз начиная писать React приложение, вы так или иначе выберите какой-то вариант:

• копи-паст вашего предыдущего проекта
• какой-то бойлерплейт или даже генератор (типа Yeoman)
• готовый фреймворк не требующий конфигурации
• пишете сами все с нуля

Каждый из способов имеет свои сильные и слабые стороны, как на длинной, так и на короткой дистанции.

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

Это вторая статья о Server Side Rendering и изоморфных/универсальных приложениях на React. Первая под названием "Упрощаем универсальное/изоморфное приложение на React + Router + Redux + Express" была больше про кастомное решение, эта же статья нацелена больше на тех, кому не хочется заморачиваться, а хочется готовое решение, с коммьюнити, и вообще поменьше головной боли с настройкой, отладкой, подбором библиотек и т.д.

+

В данной статье будем рассматривать Next.JS, который обладает преимуществами в виде отсутствия конфигурации, серверного рендеринга и готовой экосистемы.

Из коробки Next.JS не умеет работать с Redux, поэтому в процессе написания пробного проекта я выделил получившийся общий код в отдельный репозиторий next-redux-wrapper, с помощью которого в этой статье мы и соберем приложение-пример на Next.JS + Redux.

На Хабре уже было предостаточно статей про то, как делать универсальное (изоморфное) приложение на стеке React + Redux + Router + Koa/Express (Google в помощь), однако я заметил, что все они содержат повторяющийся код для серверного рендеринга. Я решил упростить задачу и выделить этот общий код в библиотеку, так и появился на свет Create React Server, работает примерно так:

import Express from "express";
import config from "./webpack.config";
import createRouter from "./src/createRouter";
import createStore from "./src/createStore";
import {createExpressServer} from "create-react-server";

createExpressServer({
  createRouter: (history) => (createRouter(history)),
  createStore: ({req, res}) => (createStore()),
  port: 3000
}));

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

На Хабре уже встречались статьи о замечательной технологии Promises, которая в будущем станет частью стандарта ECMAScript 6, однако, в этих статьях не было подробного описания, почему же они так полезны и в чем таки их преимущества. Дабы заполнить этот пробел, я решил написать эту статью.

Поговорим о случае, когда нужно автоматизировать запуск тестов и сбор статистики покрытия, к примеру, для гипотетической клиентской JS библиотеки. Задача не совсем тривиальна, поскольку для нормальной работы библиотеки требуется полноценный браузер — библиотека является визуальной оберткой над стандартными компонентами формы. Библиотека должна быть написана так, чтобы все взаимодействие с ее объектами можно было производить с помощью методов, которые они предоставляют, а не только через непосредственные манипуляции с DOM (т.е. любое действие юзера может быть запущено не только событием, допустим, клика по чему-то, но и руками через метод). Но тем не менее, надо этот DOM иметь, чтобы результаты работы методов помимо изменения внутреннего состояния объектов также отображались и в DOM. В целом напоминает приложения на Sencha (ExtJS).

Для достижения поставленных целей нужен некий контролируемый браузер, фреймворк для запуска тестов и утилита, которая позволит посчитать покрытие кода тестами, а также некоторый код, который соединит все компоненты.

Хотел бы поделиться одним из способов внедрения проигрывателя аудиофайлов для сайтов, использующих jQuery. А именно — плеером в стиле популярного сервиса Soundcloud, сделанном на HTML+CSS+JS. В догонку к недавней статье об интересном плеере jPlayer.

Сам плеер состоит из jPlayer'а, некоторого количества нехитрой верстки, и главного компонента — картинки с waveform проигрываемого файла (это наглядная картинка, на которой изображены амплитуды сигнала, отложенные по шкале времени).



С результатами этого допиливания можно ознакомиться, скачав архив со всем необходимым: http://test.dis.dj/wave/ (там же есть демка интерфейса плеера и архив с ним).

Довольно часто при верстке сайта возникает необходимость размещать блоки одинаковой ширины, но разной высоты в контейнере с переменной шириной (читай резиновом). Плюс на этот список может применяться фильтр, который JS-ом скрывает или показывает элементы списка, при этом он не должен разрушать «строки», верстку, или образовывать дыры, поэтому решения на таблицах не катят сразу. Простейший пример — каталог товаров:

Давно хотел поделиться одной интересной наработкой — а именно эмуляцией свойств min и max-width без использования expression и подобных вещей. Обвязка может показаться громоздкой, но главный ее плюс — она работает. Плюс подобные вещи можно с легкостью внедрять с помощью шаблонизатора одной строчкой кода.

Суть трюка проста:
‹table›‹tr›‹td width=1100› — максимальная ширина
‹div width=900 /› — распорка, минимальная ширина

Причем именно так, ширина не у таблицы, а у ячейки. Таким образом шире, чем 1100 таблица не будет (в данном случае), но при этом если она уже — скроллер не появляется. При этом если ширина рабочей области менее 900 — скроллер уже отобразится.

Заметно, что на Хабре в последнее время всё чаще поднимается вопрос типографики, и это не может не радовать, ибо «оттипографленные» тексты и читать приятнее, и выглядят они куда аккуратнее обычных. Да и в целом создается ощущение, что автор заботился о своих читателях.

Примерно год–полтора назад я написал свой плагин для популярного редактора TinyMCE, который умел типографить тексты посредством веб-интерфейса типографа Студии Лебедева. С того времени плагин успешно используется в проектах студий Nimax и Artilleria. После недавнего поста я решил таки его опубликовать, а также немного его усовершенствовал — добавил Типограф тов. spearance, а также Типограф студии Муравьёва. Способ типографирования можно выбрать непосредственно перед «операцией».

Усовершенствованный типограф я сегодня и представляю на суд публики.

• Демка (UTF-8): test.dis.dj/typograf
• Демка (CP1251): test.dis.dj/typograf/cp1251.php
• Качаем по адресу: test.dis.dj/typograf/typograf.zip
• Скрипты самих типографов: test.dis.dj/typograf/typograf-engines.zip (рекоммендую ознакомиться с инструкцией)

Усиленно подбираю себе VDS — задумался над вопросом сравнения производительности.

Цель данной статьи — попытка найти критерий, по которому можно сравнить VDS от различных провайдеров и выбрать объективно наиболее удачную по сочетанию цена/качество. Возможно, изложенные в статье методы не являются достоверными, но как отправная точка — вполне достаточно.

Я не знаю, уже умаялся искать приличный VDS…

Требования простые:

• русский дата центр, т.к. большинство трафа будет с русских IP
• стабильность на первый план
• ценник не заоблачный, но это не самое принципиальное
• вменяемый и быстрый саппорт (не как у инфобокса)

Сейчас имеется сервер от Infobox — это ужас. 512MB и 10% от 3Ггц Xeon под Debian5 работает медленнее, чем шаред от Majordomo ))). Плюс мега-саппорт: пишу тикет в 9:00, через час получаю ответ «мы подготавливаем ответ на ваш вопрос, ответим до 13:00».

В этом посте речь пойдет о работе РНР5 с multibyte строками посредством preg_*() функций.

Заметил интересное положение дел, вобщем-то давным давно описанное в интернете, но актуальное и по сей день (вопрос всплыл всвязи с недавним постом про trim()).

Отменнейшая JS библиотека, базированная на jQuery. Позволяет простым наведением мыши на объект увидеть все event'ы, которые на него повешены. Запускается через букмарклет.

Подробности на странице автора.

http://www.sprymedia.co.uk/article/Visual+Event

P.S. Я хотел разместить пост-ссылку, но хабру, видимо, не нравится плюс в URL…

Сегодня решил сделать то, что собирался уже давно — поставить таки кеширование скриптов у себя на сайте. Все скрипты перед отдачей пользователю собираются в один файл и сжимаются GZIP'ом — все вроде по-уму, но есть проблемка… Браузер отчаянно не хотел кешировать этот выходной скрипт.

Опытным путем было установлено, что PHP устанавливает хидеры запрета кеширования при использовании функции session_start();

В этом посте я постарался собрать все известные мне хаки для css. Многие могут усомниться в их надобности для нормальных современных браузеров, потому как большинство хаков всегда применялись только для IE, но этот пост скорее для любознательных :), в верстке хаки вообще лучше не использовать. Но так или иначе, раз они есть, грех о них не знать.

В отличие от многих хаков для той же Opera, которые также будут обработаны и Safari, я немного изменил код и Opera 9.2, Opera 9.5 и Safari 3 увидят каждый свой css.