5. API 2.1
*На самом деле, нет
• Мы продолжаем поддерживать
предыдущие мажорные версии
• Мы не озвучиваем сроки
прекращения поддержки,
потому что их нет
23. Решение 1.1
• Однако за время пути базовая
функциональность успела
подрасти
• Гигантский файл с данными
• Лишние запросы за CSS и
картинками
24. Решение 2.0
• Режем по живому:
– делим функциональность на
пакеты
– самый "маленький" пакет
(package.map) содержит самый
минимум – только карту
25. Решение 2.0
• Грузим по требованию:
– данные по масштабам и
копирайтам теперь не грузятся, а
запрашиваются при смене центра
– пользователь может подгружать
функциональность, когда она ему
реально потребовалась
26. Решение 2.0
• Экономим запросы:
– CSS теперь отдаётся вместе с JS
– Картинки кодируем прямо в CSS
27. Решение 2.0
• У нас получилось?
– минимальная сборка:
– максимальная сборка:
32. Решение 2.1
• Для этого нам пришлось очень
существенно изменить
интерфейсы
– getOverlay() -> Promise
– balloon.open() -> Promise
33. Решение 2.1
• Под капотом: новая модульность
https://github.com/ymaps/modules
• Асинхронный require
• Асинхронный provide
• Работает на клиенте и на сервере
34. Ещё проблема
• Мы стараемся держаться
плотного графика, выпуская
релиз раз в 3-4 недели
• Но мы не хотим при этом что-
нибудь сломать пользователям
35. Решение 1.0
• Можно подключать API с
указанием мажорной (1.0) или
полной (1.0.8) версии
• Мало функциональности – мало
багов
36. Решение 1.1
• А что, схема времён 1.0 по-
прежнему работает!
• А если что, мы выпустим релиз
1.1.5-а, никто же и не заметит
37. Решение 2.0
• Теперь у нас три версии:
– 2.0 – последняя выпущенная
– 2.0-stable – последняя
"стабильная"
– 2.0.xx – прямая ссылка на
конкретную версию
38. Решение 2.0
Да, но…
• Откуда у нас возьмётся
"стабильная" версия?
• В каждой версии мы правим
баги и выкатываем фичи
40. Решение 2.0-с-половиной
Теперь у нас всё просто
• stable – это тот же 2.0, только
без последних фич
• Отгадайте, какой ответ на
вопросы в техподдержку стал
самым популярным
41. Решение 2.0-с-половиной
Тогда мы стали делать RC
• Версия-релиз кандидат
доступна только по прямому
URL-у и тестируется несколько
дней
• Потом переключается 2.0
43. Решение 2.1
Мы держим два алиаса:
• 2.1-dev: релиз-кандидат,
последняя выпущенная версия
• 2.1: если в RC не найдено
ошибок, 2.1 переключается на
него
44. Решение 2.1
Будет ли оно работать?
Да кто же его знает. Практика –
критерий истины.
45. Теория vs. Практика
В отличие от задач пользователей,
проблемы "с окружающим миром"
имеют свойство случаться
ВНЕЗАПНО.
47. Решение
• Каждую картинку, каждый
фончик, каждый источник
тайлов отрисовываем в
нескольких разрешениях
• Каждый программный
интерфейс принимает ImageSet
53. DPR
• Мы переписали всё на SVG и
<canvas>
• Для IE < 9 осталась старая вёрстка
• (/me с ужасом ждёт того дня, когда
кто-нибудь запустит старый IE на
ретиновом мониторе)
54. SVG метки
Игла в яйце, яйцо в утке…
• Берём шаблон SVG
• Подставляем нужные цвета
• Формируем CSS-класс, которому в
background выставлен этот SVG
• …
• PROFIT!
59. Или вот ещё проблема
• В версии 2.0 мы используем
промисы
https://github.com/dfilatov/vow
• В ECMAScript6 включены
промисы как примитив языка
60. Или вот ещё проблема
• Промисы "по стандарту" не
совпадают ни с одной из
существующих реализаций,
включая нашу
• (какая ирония)
61. Это, конечно, не всё
Конечно же, мы заодно очень
хотели полечить и свои косяки
внедрить решения, время
которых ещё не пришло на
момент выпуска 2.0.
62. Это, конечно, не всё
• Рисовать все метки на одном
канвасе
• Управлять видимостью
объектов в кластеризаторе
• Решить проблемы с
производительностью
63. 2.1
Причины изменений в API:
Сделать хорошо
пользователю
Сделать хорошо
разработчику
Идти в ногу со
временем
Уныние и отчаяние
64. Мораль
Ты, как разработчик API, должен:
• Следить за юз-кейсами
• Следить за практикой
внедрений
• Читать техподдержку