Пишу про разработку вообще и в частности про: JavaScript, HTML5, CSS3, AngularJS, ReactJS, Agile.

Приложение на js без фреймворков

Решил написать js приложение без использование фреймворков. Не хочу сказать, что это самый правильный путь, но имеет смысл попробовать писать и так, чтобы лучше понимать как работает язык, ну и что бы лучше понимать как отвечать на вопрос “А зачем нам, собственно, все эти фреймворки? Давайти так писать!”. Вовсе не хочу сказать, что без фреймворков – это путь джедая, или что мой подход к решению самый верный. Я экспериментирую с языком в свободное от работы и личной жизни время, чего и вам желаю 😉

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

Во-первых, роутинг. Приложение конечно будет SPA, так что без этого ни куда. Быстрый поиск поиск по интернету выдал несколько готовых решений, а наглый подсчет количества зваздочек в гитхабе и активность загрузок в npm помолги выбрать победителя, им стал page. Кстати, если вам нравится что-то другое, то отпишитесь в комментариях плиз, интересно кто, что использует.

Во-вторых, темплейтинг. Хотите сами манипулировать DOM’ом? Хардкор – это ваш путь, даже завидую. Я предпочитаю отдать бразды правления тут профессионалам. Давно хотел протестировать lit-html, видимо пришло время. Пользуетесь другим решением? Отлично, как и в прошлый раз – мне интересно услышать ваше мнение.

Идем дальше, нужно как-то хранить данные в памяти и эффективно передавать между компонентами. Мой выбор redux, все хотел заиспользовать его в не контекста реакта.

Над дизайном заморачиваться вообще не будем. Берем bootstrap последней версии и все.

Кстати, по поводу стилей, нужен препроцессор, иначе не дело это. Я решил взять postcss, пора немного отойти от less, а то он прямо везде.

Заметили, что jQuery нет? Это по-дизайну, отвык я от него, предпочитаю работать без этой библиотеки, и так полно библиотек подцепил.

Теперь как все это собирать будем. Разумеется webpack, как же иначе.

Вот и все основные библиотеки, дальше начинаем решать по поводы структуры приложения.

Структура

Разумеется приложение нужно разбить на составляющие и разнести логично по папочкам. Так что бы потом тем кто придет после нас можно было разобраться в том что тут происходит. В процессе проектирования было несколько итераций с разными подходами, не буду вас мучить всеми подробностями – расскажу просто о том к чему пришел:

Теперь отдельно о каждой папке:

  • components – тут хранятся основные компоненты. Компонентами, в контексте этого приложения, я называю программные единицы, которые базируется на API унаследованном от HTMLElement.
    • AppRoot – корневой элемент приложения, будет располагаться в index.html
    • Cart – компонент корзиный, будет отображать иконку и кол-во товаров в ней
    • MainMenu – меню
    • RouteLink – ссылка для роутинга
    • Router – корневой компонента роутинга, в нем будут рендерится все страницы
  • model – все, что касается “бойлерплейта” ридакса: actions, constants, reducers.
  • pages – раутинг отображает страницы. Они являются основными контейнерами, для остальных элементов. Плюс страницы завязаны на API раутинга, поэтому они выделены в отдельную папку.
  • routeControllers – контроллеры для раутинга. По факту, это инструментарий для обработки коллбеков раутенга.
  • services – вспомогательные сервисы, дополнительный функционал, который больше никуда не поместился
  • views – рендеры, функционал lit-html

Весь исходный код конечно есть в открытом доступе js-webpack-starter

Все, кто хочет посмотреть – велкам, если есть какие рацпредложение, то конечно я хочу их услышать. Особенно, если это в виде пулл-реквестов, а то воздух сотрясать я и сам умею 🙂

Поделиться:

Конвертируем картинки в pdf в линуксе

Мне периодически требуется конвертировать картинки в pdf. Думаю, что задача достаточно распространенная, поэтому хочу порекомендовать как это сделать в линуксе без особого напряжения вообще – одной строкой:

За что отвечает каждый из параметров думаю и так понятно.

jpg-pdf

Хочу только добавить еще один вариант команды, которым иногда пользуюсь:

В этом случае картинку ужмутся на 10% (да, в команде указанно 90%, я не ошибся) и в консоле будет писаться какая картинка обрабатывается.

PS

Стоит отметить, что convert имеет еще туеву хучу настроек под все что угодно, так что если есть делание поразбираться, то там непаханное поле

Ссылки по теме:

Поделиться:

Когда помечать ошибками в формах

Проблема даже кажется надуманной – когда помечать ошибки в формах. Только вот подход – “Когда есть ошибка тогда и помечай” не особенно хорошо работает, ибо подход “в лоб” по этому совету очень быстро приведет к непонятному поведению интерфейса.

Приведу пример: у вас форма с обязательными полями, скажем поле с электро-почтой обязательно нужно заполнить. Кстати, сразу тут имеет смысл посмотреть как проверять email адрес на корректность, но сейчас не будем подробно на этом останавливаться. Вернемся к обязательному заполнению – кажется, что проверка очень простая: если поле пустое, то значит ошибка и помечаем его красным. Однако, когда пользователь зашел на страницу с формой – то она будет пустой, он ведь ее не заполнял – в этом случае помечаем красным? Конечно нет, воскликнет бывалый читатель, меня же за такое менеджеры повесят! Значит красным нужно пометить, только если поле осталось незаполненным и пользователь решил отправить форму?

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

input-error-01

Поле ввода не валидируется, пока пользователь не нажмет на кнопку “Send”, либо пока не нажмет “Enter”. После попытки отправить данные, если поле было не валидно, то оно будет подсвечено красным и данные формы не будут отправлены.

input-error-02

После того, как поле провалидировалось в первый раз, то включается “автоматическая валидация”. То есть при каждом изменении данных в поле – пользователь будет проинформирован (как минимум цветом поля) о том верны ли введенные данные.

input-error-03

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

Поделиться:

Схлопывание внешних отступов у элементов

Отличная статья с визуальными примерами о том как работает схлопывание внешних отступов у элементов – What’s the Deal with Margin Collapse?. Как-то так получилось, что не все фронтенд разработчики знают об этом поведении внешних отступов.

Когда схлопывание происходит

У двух соседних элементов.

margin-collapse-siblings-1024x490

У дочернего элемента.

margin-collapse-child-top-1024x455

margin-collapse-child-bottom-1024x455

В том случае, если высота элемента равна нулю, то схлопнуться верхний и нижний отступы.

margin-collapse-self-1024x299

Когда схлопывания не будет

margin-collapse-exception-1-1024x569

margin-collapse-exception-2-1024x525

margin-collapse-exception-3-1024x525

margin-collapse-exception-4-1024x526

margin-collapse-exception-5-1024x478

Поделиться:

Вынести папку из репозитория с сохранением git истории

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

Теперь в проекте остались только файлы из папки. Причем файлы будут лежать в корне основной директории <git repository A directory>

Давайте посмотрим как это делается на конкретном примере – выделим папку “doc” из репозитория underscore:

Вот и все, теперь в папка “underscore” только файлы документации.

Ссылки по теме:

Поделиться:

Библиотека компонентов

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

В нашем примере есть три компонента, которые мы хотим использовать везде:

  • Button.jsx
  • Checkbox.jsx
  • Form.jsx

Да, пример будет на базе реакта, но какая разница, все тоже самое будет и для всего остального. Сама имплементация этих компонентов не имеет значения, просто предположим, что они лежат в папках рядом и пути до них вот такие:

  • Button.jsx        →   “./Button/Button”
  • Checkbox.jsx   →   “./Checkbox/Checkbox”
  • Form.jsx          →   “./Form/Form”

Для начала нам потребуется файл, который будет их всех импортировать. Это будет наша “точка входа” для сборки.

components.js

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

components.d.ts

И самое главное – пишем конфиг для вебпака. Тут есть несколько моментов.

  • Указываем путь до файла components.js
  • Выбираем как библиотека будет собрана через libraryTarget (в моем случае это umd)
  • В externals указываем какие библиотеки не должны быть частью собранной библиотеки. То есть эти библиотеки должны будут быть включены в проекте, который использует эти компоненты. Исключительно экономия размера.

webpack.config.js

Вот и все – можно запускать и использовать.

Поделиться:

Chrome будет блокировать рекламу не отвечающую стандартам

Начиная с 15 февраля этого года Chrome будет блокировать рекламу, которая не отвечает стандартам описанным в Better Ads Standards. Разумеется, что у хрома нет цели убить рекламу в интернете и можете быть спокойны, что реклама в результатах поиска гугла никуда не денется 🙂 Вместе с тем разработчики самого популярно браузера хотят сделать интернет лучше и, как ни странно, помочь росту рынка рекламы.

Тут дело вот в чем. Основная проблема плагинов, блокирующих рекламу, в том что они рубят все объявления. Вместе с тем не вся реклама одинаково раздражает пользователя и если бы все сайты использовали более адекватных подход в рекламе, то и плагины-блокировщики не пользовались бы таким успехом. Ну вот для примера – разве вас сильно раздражает реклама в результатах поиска? Думаю, что большинство согласится с тем, что из-за нее точно тратить время на установку плагина никто бы не стал. Если же блокировщик не пользуется популярностью, то все от этого выигрывают – сайты зарабатывают на показах, а рекламодатели получают доступ к своей аудитории.

Итак, какие же рекламные сообщения не попадают под стандарт. Подход различает то, как пользователь просматривает сайта – на десктопе или на мобильном устройстве. На десктопах будут блокироваться:

  • Попапы внутри страницы, которые закрывают контент.
  • Видео реклама, которая начинает авто-проигрываться как только пользователь зашел на страницу.
  • Широкие прикрепленные баннеры.

На мобильных устройствах:

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

better-ads-standards

В сухом остатке – это вполне себе прагматичные меры. Интернет становится лучше, потому что только так все в итоге получат выгоду.

Поделиться:

Как не надо писать статьи об оптимизации

На днях в рассылке пришла ссылка на статью “How I Cut My React Javascript Bundle Size In Half With Three Lines of Code” (“Как я тремя строчками код в два раза уменьшил бандл React приложения”). Огонь название, не находите? Сразу хочется пойти и уточнить как же это сделать, ведь проблема-то насущная – размер кода редко когда уменьшается, он все норовит вырасти. Однако, каким же фейком оказалась эта статья.

В чем основной совет статьи? Заменить react на preact, вот и все! Взять и заменить один фреймворк на другой, ничего же плохого не может случиться! Какие проблемы? Действительно, если автор в основном пишет приложения вроде ведения списка дел, то все будет в шоколаде, без сомнений. А что делать, если в приложении 20 страниц контента со сложной логикой? Все же сломается, потому что эти фрейморки не на 100% взаимозаменяем. Я уже молчу про баги в работе preact’а.

Поделиться:

Так ли нужны “хлебные крошки” (breadcrumbs)

Для начала несколько слов о том что такое “хлебные крошки” (breadcrumbs), чтобы мы все могли говорить на одном языке. “Хлебные крошки” – это элемент навигации веб-страницы, который позволяет дать информацию пользователю о том, в каком контексте он находится. Например:

breadcrumbs-navigation-example

Идея в том, что пользователь может решить дальше исследовать тему, которую раскрывает текущая страница. При помощи “хлебных крошек”, например, может подняться на уровень выше и осмотреть какая информация находится там. Это сделано для того чтобы посетителю не нужно было искать нужный раздел в меню. Это может быть проблемой, особенно если разделов много, а их вложенность может быть достаточно глубокой.

Скорее всего именно по этому Амазон и другие торговые платформы используют их. Меню этих сайтов представляет из себя сложный каталог, в котором найти что-то ценное не представляется возможным. Как следствие пользователи используют поиск и, найдя примерно нужный товар, могут уже начать исследовать категорию, в которой он находится. Так вот как-то же нужно показать информацию об этой категории – для этого хлебные крошки и используются.

Вместе с тем вроде никто другой их не применяет. Самый яркий пример не менее сложного сайта, который обходится без них, это Гугл аналитикс. Как же он умудряется справляться без них?

google-analytics

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

Я уже не говорю о том, что сам подход – использовать “хлебные крошки” – уже морально устарел. Он был хорош в начале развития интернета, когда сайты были статичные и нужно было решать проблемы статичными же методами. Сегодня мы можем изменить подход и, немного подумав, сделать-таки интерфейс удобным и не обремененным ненужным функционалом.

Поделиться:

Дизайн админки – сумбур графиков

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

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

dashboard-activity-feed

У меня сразу вопрос – неужели никто не захочет менять временные рамки?

Внимательный читатель может заметить, что под графиком справа есть “Timeline: 2014”. Однако, это выглядит как выбор из списка вариантов – например, разные года, или, хотя бы, разные месяцы. А если мне нужен другой промежуток времени, то никак? Если, например, мне нужно пол года, то это тоже будет в списке? Длинный список получится.

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

Автор говорит, что это админка для конкретного продукта. Продукт возможно никогда не был выпущен, но это не имеет значения. Дизайнер мог решить потренироваться и выпустил вот такой дизайн даже для вымышленной задачи. Это отличная цель, только резултать не понятно как применять.

И вот такие дизайнерские решения есть сполш и рядом – они оторваны от реального применения, никак не относятся к реальному рынку и живут только в фантазии. Этот разрыв просто вымораживает иногда – поэтому повсеместно такие проблемы с интерфейсами.

Поделиться: