Звучит тревожно, но по большей части это не так — сегодня. Вот что мы выяснили, мигрируя реальный проект с 3.44.0 на 3.47.2, и одно широко разошедшееся утверждение про этот релиз, которое не выдерживает столкновения с кодом.

Сегодня ничего не горит​

Мы взяли живой проект, перевели его с 3.44.0 на 3.47.2 и запустили: flutter analyze чистый, тесты зелёные, библиотеки по-прежнему внутри SDK и не помечены как deprecated. Депрекация назначена на ноябрьский релиз. Вот тогда часы и пойдут.

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

Миграция — одна команда, но с двумя ловушками​

dart fix --apply --code=migrate_design_widgets

Ловушка первая: простой dart fix --apply этого не сделает. Фикса нет в наборе по умолчанию; без --code=migrate_design_widgets команда отработает, отрапортует об успехе и не изменит ничего по делу. Это тот тип отказа, который читается как «уже мигрировано».

Ловушка вторая: она пишет material_ui: any в ваш pubspec. any значит, что следующий ломающий релиз этого пакета приедет к вам в сборку молча. Замените на каретку с версией сразу, как фикс отработает.

Утверждение, которое неверно: ChangeNotifier никуда не уехал​

Самая часто повторяемая фраза про этот релиз — что ChangeNotifier и компанию вынесли из SDK в package:listen. В 3.47.2 произошло не это.

Классы по-прежнему в SDK и не помечены как deprecated. listen — это вторая, независимая реализация тех же имён, а не новый дом для старых. Это разные типы, и компилятор относится к ним именно так:

• передайте ValueNotifier из listen во flutter'овский ValueListenableBuilder — и получите ошибку компиляции, а не тонкий баг в рантайме;
• то же самое в обратную сторону и для любой другой пары с общим именем.

Где listen действительно к месту — код, в котором нет Flutter: сервер, CLI, логика, общая для того и другого. Там типов из SDK никогда не было, а теперь есть эквивалент. Внутри Flutter-приложения переход на него сегодня не даёт ничего и стоит вам совместимости по типам с каждым виджетом, который ждёт версию из SDK.

Primary constructors сами не включатся​

В Dart 3.13 приехали primary constructors, и они за флагом версии языка. Без sdk: ^3.13.0 в pubspec.yaml вы получите experiment_not_enabled даже на правильном SDK — тулчейн в порядке, это проект не просит.

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

Остальное​

Impeller по умолчанию на десктопе, iOS 15 и macOS 12 как новые нижние границы и работа над Wasm — всё реальное, ничего срочного, и ни на что из ваших дел в этом месяце не влияет.

Что реально сделать до ноября: прогнать миграцию в ветке, нормально запинить material_ui и не трогать ChangeNotifier.

Проверено миграцией живого проекта с 3.44.0 на 3.47.2 — before/ и after/ собираются и проходят тесты каждый на своём SDK. Видеоразбор — на YouTube.

Вот во что она обходится на самом деле, в том порядке, в каком приходят счета.

Поиск никогда не был проблемой​

Фреймворк хранил одну колонку userIdentifier и искал по строгому равенству. Попроси его найти профиль по телефону или почте — и расширять просто негде: не потому что запрос сложный, а потому что сама аутентификация требует, чтобы эта колонка существовала. Убери её — и ядро падает на старте.

Так что первая правка — не «искать по двум полям». Это дать приложению право голоса в том, как находится пользователь:

DwAuthConfig(
  findUserProfileByIdentifier: (session, identifier) async {
    // приложение само решает, что значит «тот же самый человек»
  },
);

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

Поиск по двум полям сам по себе ничего не чинит​

Вот эта часть нас и удивила, и ради неё написан этот пост.

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

Чтобы заполнить эту колонку, нужен способ привязать второй канал к существующему аккаунту — а значит, addAuthProvider и changeIdentifier должны реально работать. У нас оба бросали UnimplementedError, и экрана для этого не было ни в одном макете. Пока его нет, вход с другого канала по-прежнему тихо создаёт второй аккаунт, ровно как и раньше.

Дубли уже есть​

Дальше идёт то, что отложить не получится. Мы пошли добавлять уникальные индексы на phone и email и обнаружили, что уникальных индексов не было вообще — ни на новых колонках, ни на старом userIdentifier. Две строки с одинаковым значением уже были легальны, и поиск возвращал ту, которую базе захочется отдать.

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

Слияние — это событие, а не действие​

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

Что мы сказали бы себе неделю назад​

• «Вход по телефону или почте» — задача не про экран авторизации. Это задача про идентичность профиля, а экран — последние пять процентов.
• Выкатывайте привязку второго канала в том же релизе. Без неё фича — это поиск, который ничего не находит.
• Проверяйте уникальные индексы до того, как что-то пообещали. У нас их не было за всю жизнь проекта, и никто не заметил, потому что ничто их не требовало.
• Проверяйте на живой базе полным кругом: регистрация по телефону, привязка почты, вход по почте в тот же аккаунт, одна строка в таблице. У нас 23 серверных теста, включая этот проход; версия этой статьи, написанная по чтению кода, была бы неверна в двух местах.

Со стороны фреймворка это приехало в ядро dartway 0.12.1 — резолвер аутентификации и работающий changeIdentifier. Если вы на более ранней версии, интересная часть — миграция, а не API.