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

Плагин для борьбы с CORS ошибками в хроме

Я уже писал пост о там, что можно сделать с CORS ошибками в хроме. В тот раз все решалось проставлением флагов, никаких дополнительных плагинов ставить не нужно было. В этот раз поговорим о более масштабном решении, которое бы позволило переписать все хедеры, как на выходе, так и на входе.

Ведь в чем проблема CORS ошибок – либо браузер блокирует запрос из-за того, что сервер возвращает не соответствующий хедер “Access-Control-Allow-Origin”. Либо сам сервер блокирует запрос потому что его не устраивает то, что пришло в хедерех “Referer” или “Origin”. В обоих случаях все упирается в то, что послал браузер, а значит может быть переделано.

Для того, чтобы с эти справиться ставим плагин requestly.

requestly-home-page

requestly-modify-headers

Скорее всего вам потребуется добавить 3 правила.

Два первых правила предназначены для изменения двух хедеров в Request:

  • Referer
  • Origin

У обоих в значении должен быть домен, до которого нужно достучаться.

В третьем правиле нужно модифицировать хедер в Response, который называется “Access-Control-Allow-Origin”. Устанавливаем его в значение “*” (звездочка без кавычек).

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

Поделиться:

Toast UI – набор компонентов для интерфейсов

Коротенечко, тезисно о найденной библиотеки. Ребята из китайской компании toast.com постоянно пилят UI компоненты для интерфейсов. Мне пока не удалось воспользоваться ни одним из них (не было необходимости), но суля по количеству “звездочек” на гитхабе народ ценит и любит их решения.

Итак что, у нас есть:

Графики

Набор графиков. Все написано своими руками, не зависит от сторонних библиотек.

toast-ui-charts

Календарь

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

toast-ui-calendar

Редактор

HTML редактор – достаточно распространенный компонент. Где я только такие не встречал.

toast-ui-editor

Таблицу для вывода данных

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

toast-ui-grid

Поделиться:

Пишем модульный код для контентного сайта

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

conditioner

Собственно, не все сайт должны быть одностраничными. Особенно если речь идет об индексации и времени рендера для конечного пользователя. Ничто так быстро не рендерится в браузере как обычный html, а уж если нужно поддерживать разные устройства с разным объемом памяти, то вот тут и начинаются танцы с бубном.

Так вот в случае с контентым сайтом “js сахар” добавляется модульно, там где нужна интерактивность:

  • Поиск с автозаполнением
  • Форми с проверкой валидности полей
  • Выпадающий список с поиском
  • и так далее

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

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

Итак, давайте посмотрим на вариант реализации. Разумеется, мне с самого начала хочется использовать webpack, а не городить какие-то другие решение. Все по тому что и привычно и хочется посмотреть как его применить. Структура папок будет вот такая:

Страницу долго придумывать не будем, просто возьмем прием работы бустрапа – Pricing example. Я просто взял весь внутренний код и начал работать с ним

content-js-site

Добавим немного интерактивности, пусть при наведении мышкой на карточку с ценой она увеличивается. Все исключительно на js, что бы показать работу. Для анимации будем использовать библиотеку animejs – достаточно простой вариант анимации не на базе css.

Теперь сама кодовая база. Основной файл, через который webpack будет компилировать все остальные будет index.js. В этом файле описываем как вебпаку нужно будет загружать модули – moduleImport. Это стандартный мета-синткас менеджера сборки.

Теперь сам модуль для анимации карточки – modules/priceCart.js

Теперь добавляем код модуля в сам html:

Вот, собственно, и все. Можно продолжать экспериментировать 🙂 Кстати, полный код находится вот здесь: https://github.com/artemdemo/content-js-site

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

Поделиться:

Используем nvm для работы с node.js

Часто, работая над несколькими проектами, требуется использовать несколько версий node. Да даже если не работаешь над несколькими очень хочется самому управлять тем какая версия ноды стоит на компьютере. Потому что не все библиотеки проекта успевают обновиться под обновленный API.

Отдельно хочется сказать про мак. Потому что на маке все хочется устанавливать через brew, в этом нет никаких проблем пока они не начинаются 🙂 – особенно, когда вдруг “апнулась” версия ноды и весь проект перестал собираться. Поэтому имеет смысл использовать сторонний менеджер версий, например nvm.

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

Устанавливаем сам nvm:

Теперь добавляем скрипты для запуска nvm в профиль баша (~/.bash_profile, ~/.zshrc, ~/.profile, or ~/.bashrc):

Особенно внимательно проверяем профили оболочки (если таковая используется, например, ~/.zshrc). Там тоже должен быть прописан запуск nvm.

Ставим lts версию ноды:

Теперь указываем какая версия ноды должна запускаться по умолчанию, например стабильная (если установлена только lts, то будет выбрана она):

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

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

Поделиться:

Топ 10 js ошибок из 1000+ проектов

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

Так вот эти ребята написали статью с обзором 10 самых распространенных js ошибок, которых их сервис поймал. Достаточно интересное чтиво. Вот топ лист, кстати:

top-js-error-msgs

Ребята конечно написали статью для того чтобы пропиарить свой сервис. Никаких к ним при этом претензий конечно быть не может. Все правильно делают. Вместе с тем и нам очень много пользы.

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

Например, когда сафари вабрасывает ошибку с сообщением “TypeError: ‘undefined’ is not an object”, то хром напишет “Uncaught TypeError: Cannot read property bar of undefined”. Хотя это будет один и тот же случай. Для иллюстрации посмотрим вот как эта ошибка выглядит в хроме:

cannot-read-property

И вот как она же выглядит в сафари:

safari-undefined-error-msg

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

Поделиться:

Приложение на 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” только файлы документации.

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

Поделиться: