1. yandex maps
TRANSCRIPT
JS API Яндекс.Карт 2.1Почему и зачем мы меняем API?
Сергей Константиновруководитель службы разработки API Яндекс.Карт
Обратная совместимость• Экономит деньги• Держит карму
в чистоте• Клиенториентировано!
API 2.1Встречайте: JS API 2.1:• Мы сломали обратную
совместимость*
API 2.1*На самом деле, нет
API 2.1*На самом деле, нет• Мы продолжаем поддерживать
предыдущие мажорные версии• Мы не озвучиваем сроки
прекращения поддержки, потому что их нет
API 2.1
Зачем?• Новые технологии• Новые тренды в дизайне• Новые времена• Нам надоело поддерживать старый
код, мы хотим писать новый• Прост))
Зачем?Правильный ответ:• Чтобы решать задачи
пользователя
ЗадачиПо большому счёту, есть два типа задач:• поддержка "железа"• поддержка кейсов
ЗадачиС поддержкой кейсов всё сложнее, чем кажется. Кейсы есть:• у нас• у вебмастеров• у пользователей
ЗадачиДавайте лучше на конкретных примерах
Элементы управленияВ API 2.0 у нас есть прекрасный набор элементов управления
Проблема
Проблема
Что делать?• Добавить fullscreen• Заодно чуть
лучше станетна мобильных
Что делать?• Адаптивные контролы
Что делать?• Добавить стандартные наборы
элементов управления• Лучший программный
интерфейс – хорошо подобранный default
Что делать?• История успеха:http://tech.yandex.ru/events/yac/2013/talks/1113/
Вывод?• Иногда разработчику нужно
дать свободу так, чтобы он ей не пользовался
Ещё проблема• Объём кода в API давно вышел
за пределы разумного• Долго грузится, долго парсится,
долго исполняется• 800+ различных сущностей
Решение 1.0• Грузим всё сразу:
• Не айс
Решение 1.1• Выделяем дополнительную
функциональность в подгружаемые модули:
Решение 1.1• Однако за время пути базовая
функциональность успела подрасти
• Гигантский файл с данными• Лишние запросы за CSS и
картинками
Решение 2.0• Режем по живому:– делим функциональность на
пакеты– самый "маленький" пакет
(package.map) содержит самый минимум – только карту
Решение 2.0• Грузим по требованию:– данные по масштабам и
копирайтам теперь не грузятся, а запрашиваются при смене центра
– пользователь может подгружать функциональность, когда она ему реально потребовалась
Решение 2.0• Экономим запросы:– CSS теперь отдаётся вместе с JS– Картинки кодируем прямо в CSS
Решение 2.0• У нас получилось?– минимальная сборка:
– максимальная сборка:
Решение 2.0• Отгадайте, сколько
пользователей грузит минимальную сборку?
Решение 2.0• На самом деле, так не работает• Не нужно надеяться на то, что
пользователь решит проблему, которую вы сами решить не смогли
Решение 2.1• Один package.full• Модели грузим сразу,
отображения – по требованию
Решение 2.1• Например, пользователь
включил линейку:
• Ушёл запрос за графикой:
Решение 2.1• Для этого нам пришлось очень
существенно изменить интерфейсы– getOverlay() -> Promise– balloon.open() -> Promise
Решение 2.1• Под капотом: новая модульностьhttps://github.com/ymaps/modules• Асинхронный require• Асинхронный provide• Работает на клиенте и на сервере
Ещё проблема• Мы стараемся держаться
плотного графика, выпуская релиз раз в 3-4 недели
• Но мы не хотим при этом что-нибудь сломать пользователям
Решение 1.0• Можно подключать API с
указанием мажорной (1.0) или полной (1.0.8) версии
• Мало функциональности – мало багов
Решение 1.1• А что, схема времён 1.0 по-
прежнему работает!• А если что, мы выпустим релиз
1.1.5-а, никто же и не заметит
Решение 2.0• Теперь у нас три версии:– 2.0 – последняя выпущенная– 2.0-stable – последняя
"стабильная"– 2.0.xx – прямая ссылка на
конкретную версию
Решение 2.0Да, но…• Откуда у нас возьмётся
"стабильная" версия?• В каждой версии мы правим
баги и выкатываем фичи
Решение 2.0-с-половинойМы разделяем релизы• За фичовым релизом
обязательно следует дебажный• stable переключается только на
дебажный
Решение 2.0-с-половинойТеперь у нас всё просто• stable – это тот же 2.0, только
без последних фич• Отгадайте, какой ответ на
вопросы в техподдержку стал самым популярным
Решение 2.0-с-половинойТогда мы стали делать RC• Версия-релиз кандидат
доступна только по прямому URL-у и тестируется несколько дней
• Потом переключается 2.0
Решение 2.0-с-половинойОтгадайте, сколько багов нам зарепортили в версиях-релиз кандидатах?
Решение 2.1Мы держим два алиаса:• 2.1-dev: релиз-кандидат,
последняя выпущенная версия• 2.1: если в RC не найдено
ошибок, 2.1 переключается на него
Решение 2.1Будет ли оно работать?Да кто же его знает. Практика – критерий истины.
Теория vs. ПрактикаВ отличие от задач пользователей, проблемы "с окружающим миром" имеют свойство случаться ВНЕЗАПНО.
Например• Экраны с device pixel ratio > 1
победоносно шествуют по планете
Решение• Каждую картинку, каждый
фончик, каждый источник тайлов отрисовываем в нескольких разрешениях
• Каждый программный интерфейс принимает ImageSet
РешениеСколько существует разных DPR?• 1x (спасибо, кэп)• 2x
DPRСколько существует разных DPR?• 1.5x (старые Андроиды)• 3x (новые Андроиды)
DPRСколько существует разных DPR?• 1.7 (LG Optimus)• 1.8 (Samsung Galaxy Mega 6.3)• 2.25 (Opera Mobile)
DPRСколько существует разных DPR?• 1.325 (Asus Nexus 7)• 5:3, 15:9 (Nokia)
DPR(здесь должна быть картинка
"да, мы упоролись",но всё понятно и так)
DPR• Мы переписали всё на SVG и
<canvas>• Для IE < 9 осталась старая вёрстка• (/me с ужасом ждёт того дня, когда
кто-нибудь запустит старый IE на ретиновом мониторе)
SVG меткиИгла в яйце, яйцо в утке…• Берём шаблон SVG• Подставляем нужные цвета• Формируем CSS-класс, которому в
background выставлен этот SVG• …• PROFIT!
SVG метки
SVG меткиПробуем на практике:• Берём шаблон SVG• Подставляем нужные цвета• Формируем CSS-класс, которому в
background выставлен этот SVG• …• Слайдшоу!
SVG меткиДобавляем пару шагов:• Берём канвас• Делаем drawImage, передавая
закодированный SVG как data:uri• Преобразуем в закодированный PNG• …• Вот теперь PROFIT!
SVG меткиК сожалению, обратная совместимость пала смертью храбрых
Или вот ещё проблема• В версии 2.0 мы используем
промисыhttps://github.com/dfilatov/vow• В ECMAScript6 включены
промисы как примитив языка
Или вот ещё проблема• Промисы "по стандарту" не
совпадают ни с одной из существующих реализаций, включая нашу
• (какая ирония)
Это, конечно, не всёКонечно же, мы заодно очень хотели полечить и свои косяки внедрить решения, время которых ещё не пришло на момент выпуска 2.0.
Это, конечно, не всё• Рисовать все метки на одном
канвасе• Управлять видимостью
объектов в кластеризаторе• Решить проблемы с
производительностью
2.1Причины изменений в API:
Сделать хорошо пользователю
Сделать хорошо разработчику
Идти в ногу со временем
Уныние и отчаяние
МоральТы, как разработчик API, должен:• Следить за юз-кейсами• Следить за практикой
внедрений• Читать техподдержку
МоральТы, как разработчик API, должен:• Периодически выпускать новые
версии
Всем спасибо!Вопросы?• clubs.ya.ru/mapsapi• (facebook|vk).com/ymapsapiВ крайнем случае:• Сергей Константинов