Comments 7
Я не андроид разработчик и не пишу на jetpack compose, но статья мне понравилась. Приятно написано и идеи вроде интересные)
По поводу первой части. Есть же safety api для навигации через Serializable классы, и toRoute<Class> функцию, все удобно и без этих строк рандомных.
По поводу второй части, кодогенерация это хорошо, но как будто не сюда) Люблю Compose за его линейность, когда можно покликать по функциями или же просто по названиям искать код, а тут появляется случайный код в build. В библиотеках по типу room/dagger, так как в одном это возможность скрыть весь ужас sqlite апи, а в другом создание графа зависимостей во время компиляции для определения вероятных ошибок. Здесь же не вижу причин это делать, только размывает контекст. Но работа проделана хорошая)
Прим. Под частью подразумевал не части из статьи
Огромное спасибо за такой развернутый и очень вдумчивый комментарий! Это именно та техническая дискуссия, ради которой и пишутся статьи на Хабре. Вы подняли два абсолютно верных и важных вопроса.
1. По поводу toRoute<Class> и Serializable API.
Вы на 100% правы. Официальная библиотека сделала гигантский шаг вперед, и возможность навигироваться на Serializable/Parcelize класс — это фантастическое улучшение. Оно действительно решает проблему типобезопасной передачи данных.
Моя основная "боль", которую я пытался решить, лежит немного в другой плоскости — не в самой передаче данных, а в объявлении навигации и ее вызове. Даже с новым API, разработчику все еще нужно вручную:
Создавать
composableблок вNavHostдля каждого экрана.Вручную прописывать
arguments = listOf(...), если у аргументов есть значения по умолчанию.Вручную настраивать
enterTransition,exitTransitionи другие анимации для каждого экрана, если они отличаются от стандартных.Вручную реализовывать логику
popUpTo.
Моя библиотека с помощью KSP берет на себя именно эту рутину, генерируя весь NavHost целиком на основе одной лишь аннотации над экраном. То есть, она является "надстройкой" над новым type-safety API, которая автоматизирует его настройку.
2. По поводу философии кодогенерации.
Насчет второго пункта — о "линейности" Compose и "размытии контекста" — это 100% валидный и, я бы сказал, философский вопрос. Я очень уважаю эту точку зрения, и для меня самого это был компромисс.
Мы действительно "платим" за магию кодогенерации небольшой потерей "прозрачности" (сгенерированный код не виден сразу), но взамен я старался получить другие преимущества:
Единый источник правды: Вся конфигурация экрана (его аргументы, анимация, DI-потребности) теперь находится в одной аннотации над Composable-функцией. Она не "размазана" по
enum-классам, билдеруNavHostи ViewModel. На мой взгляд, это наоборот, концентрирует контекст в одном месте.Сокращение рутины: В проектах с десятками экранов это экономит сотни, если не тысячи, строк повторяющегося кода, который нужно писать и поддерживать.
Но я абсолютно согласен, что это выбор. Кому-то комфортнее видеть весь код явно, даже если он повторяющийся. Моя библиотека — для тех, кто, как и я, готов немного "отпустить контроль" в обмен на автоматизацию этой конкретной рутины.
Еще раз огромное спасибо за такой качественный фидбэк! Это очень ценно.
При чтении статьи действительно большим упущением казалось то, что автором не изучен вопрос с type safe api. Type-safe подход уже стал стандартом в современных приложениях на Compose. Например, в приложении "Now in Android" даже роуты без аргументов объявлены с помощью type safe api, в виде object. То есть стандартная библиотека уже есть и работает похожим образом, но требует писать меньше кода и и не требует кодогенерации.
Type safe api не требует прописывать arguments, так что этой боли также уже не должно быть.
В "Продвинутые возможности и результат" предлагается использовать опять же строки для объявления роута (параметр route типа NavigationAction). То есть магические строки фактически остаются.
Также вопросы вызывает тезис об экономии тысяч строк на десятках экранов. С использованием type safe api объявление composable экрана занимает 3 строки, его добавление в NavHost — еще одну строку. Чтобы экономить хотя бы сотни строк, проект должен быть уровня бигтеха, а на десятках экранов экономия будет незначительной и лично для меня не оправдала бы внедрение новой библиотеки.
В целом, приятно видеть инициативу и попытки улучшить навигацию, но, на мой взгляд, важно учитывать уже существующие решения.
Не понимаю, чем это решение лучше, чем compose-destinations? CD существуют уже больше 3х лет, задолго до создания этой библиотеки, и обладает бОльшим функционалом.
Также не понял где был "обгон" заявленный в заголовке. У самой compose навигации давно есть тоже своя система типобезопасной навигации через котлин-сериализацию, около года.
Однако библиотека в статье была создана около недели назад, судя по истории коммитов.
По структуре первого коммита можно увидеть что она недавно была сгенерирована из свежего шаблона, аргумент с тем, что она была в закрытом доступе, отпадает.В чем был обгон?
Зачем типобезопасную навигацию изобрели ещё раз?
Я обогнал Google?