Очень вам благодарен за такой отзыв! Я как раз старался написать не просто сухую техническую инструкцию, а поделиться самой историей и подходом. Вдвойне приятно, что это было интересно читать даже за пределами Android-комьюнити. Спасибо!
Огромное спасибо за такой развернутый и очень вдумчивый комментарий! Это именно та техническая дискуссия, ради которой и пишутся статьи на Хабре. Вы подняли два абсолютно верных и важных вопроса.
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. На мой взгляд, это наоборот, концентрирует контекст в одном месте.
Сокращение рутины: В проектах с десятками экранов это экономит сотни, если не тысячи, строк повторяющегося кода, который нужно писать и поддерживать.
Но я абсолютно согласен, что это выбор. Кому-то комфортнее видеть весь код явно, даже если он повторяющийся. Моя библиотека — для тех, кто, как и я, готов немного "отпустить контроль" в обмен на автоматизацию этой конкретной рутины.
Еще раз огромное спасибо за такой качественный фидбэк! Это очень ценно.
Очень вам благодарен за такой отзыв! Я как раз старался написать не просто сухую техническую инструкцию, а поделиться самой историей и подходом. Вдвойне приятно, что это было интересно читать даже за пределами Android-комьюнити. Спасибо!
Огромное спасибо за такой развернутый и очень вдумчивый комментарий! Это именно та техническая дискуссия, ради которой и пишутся статьи на Хабре. Вы подняли два абсолютно верных и важных вопроса.
1. По поводу
toRoute<Class>иSerializableAPI.Вы на 100% правы. Официальная библиотека сделала гигантский шаг вперед, и возможность навигироваться на
Serializable/Parcelizeкласс — это фантастическое улучшение. Оно действительно решает проблему типобезопасной передачи данных.Моя основная "боль", которую я пытался решить, лежит немного в другой плоскости — не в самой передаче данных, а в объявлении навигации и ее вызове. Даже с новым API, разработчику все еще нужно вручную:
Создавать
composableблок вNavHostдля каждого экрана.Вручную прописывать
arguments = listOf(...), если у аргументов есть значения по умолчанию.Вручную настраивать
enterTransition,exitTransitionи другие анимации для каждого экрана, если они отличаются от стандартных.Вручную реализовывать логику
popUpTo.Моя библиотека с помощью KSP берет на себя именно эту рутину, генерируя весь
NavHostцеликом на основе одной лишь аннотации над экраном. То есть, она является "надстройкой" над новым type-safety API, которая автоматизирует его настройку.2. По поводу философии кодогенерации.
Насчет второго пункта — о "линейности" Compose и "размытии контекста" — это 100% валидный и, я бы сказал, философский вопрос. Я очень уважаю эту точку зрения, и для меня самого это был компромисс.
Мы действительно "платим" за магию кодогенерации небольшой потерей "прозрачности" (сгенерированный код не виден сразу), но взамен я старался получить другие преимущества:
Единый источник правды: Вся конфигурация экрана (его аргументы, анимация, DI-потребности) теперь находится в одной аннотации над Composable-функцией. Она не "размазана" по
enum-классам, билдеруNavHostи ViewModel. На мой взгляд, это наоборот, концентрирует контекст в одном месте.Сокращение рутины: В проектах с десятками экранов это экономит сотни, если не тысячи, строк повторяющегося кода, который нужно писать и поддерживать.
Но я абсолютно согласен, что это выбор. Кому-то комфортнее видеть весь код явно, даже если он повторяющийся. Моя библиотека — для тех, кто, как и я, готов немного "отпустить контроль" в обмен на автоматизацию этой конкретной рутины.
Еще раз огромное спасибо за такой качественный фидбэк! Это очень ценно.