Эффекты и Compose
В эфире регулярная рубрика "в интернете кто-то посрался". Сегодня на повестке дня вот этот обмен твитами. Там всё начинается с будничного хаяния Compose, а потом туда приходит один из разработчиков Compose и тут понеслась.
Ключевые тезисы:
- Эффекты использовать вообще плохая практика
- Наша же документация в этом смысле учит людей плохому, мы пытались донести это деврелам, они не слушают
- Функцию remember тоже лучше не использовать за исключением некоторых юзкейсов типа анимаций. ✏️
И это довольно забавные инсайты. Понятно откуда берётся это желание, чтобы Composable функции были (условно) чистыми, но в жизни по моему это не очень работает, учитывая горы нашего легаси за миром композа.
Плохо, что альтернативы не очень-то и раскрыты. Я покопался в нашей кодовой базе и попытался сформулировать наши юзейсы для эффектов.
- Во-первых они всё равно используются где-то под капотом collectAsState*. Считается ли это плохой практикой я не уверен. Но без этого, кажется, мы вообще не можем в том месте, где пытаемся связать Composable функцию с каким-то логическим компонентом, например вьюмоделькой, буквально по всех популярных подходах к архитектуре.
- Во-вторых это подписки на всякие Flow, т.к. только внутри эффектов у нас есть скоуп. И всё это можно было бы разрулить где-то в тех же логических компонентах, если бы не нужно было на эти события взаимодействовать с UI или платформенными штуками. Где-то у нас всратые Material апишки типа боттомшитов и снэкбаров, которые ни спрятать ни показать в m2 без корутин нельзя. Где-то нужен активити контекст, например, чтобы другую активити открыть. Где-то у нас под листвой вообще грабли в виде AndroidView, с которым нужно общаться императивно. Где-то приходится заворачивать в это всё пермишны и Result API. И как быть без эффектов то?
- В-третьих это часто используется как колбэк от UI, что он там начал рисоваться, типа "бизнес логика, запускайся". В этом кейсе я согласен, можно это на уровень Composable и не тянуть. С remember я тоже по большей части согласен в продуктовом коде, но когда пишем библиотеку уже не очень. Ребята в аккомпанисте соврать не дадут.
В общем типичный срач между тем, кто пишет инструмент и предполагает как его нужно использовать, и теми кто пытается применить его на практике и борется со всем миром лишь бы оно вообще завелось, и пофиг на то насколько это идеологически чисто. Можно понять обе стороны, но обе не сильно-то и правы. Мы понимаем, что это всё лучше не использовать, если можно обойтись. Нам тоже хотелось бы писать такие Composable функции, которые просто принимали бы уже готовый стейт. Но это невозможно, или с точки зрения существующих библиотек (от других отделов гугла же), или с точки зрения легаси, или с точки зрения перформанса, или просто альтернатива настолько бойлерплейтная, что всему комьюнити проще так.
В эфире регулярная рубрика "в интернете кто-то посрался". Сегодня на повестке дня вот этот обмен твитами. Там всё начинается с будничного хаяния Compose, а потом туда приходит один из разработчиков Compose и тут понеслась.
Ключевые тезисы:
- Эффекты использовать вообще плохая практика
- Наша же документация в этом смысле учит людей плохому, мы пытались донести это деврелам, они не слушают
- Функцию remember тоже лучше не использовать за исключением некоторых юзкейсов типа анимаций. ✏️
И это довольно забавные инсайты. Понятно откуда берётся это желание, чтобы Composable функции были (условно) чистыми, но в жизни по моему это не очень работает, учитывая горы нашего легаси за миром композа.
Плохо, что альтернативы не очень-то и раскрыты. Я покопался в нашей кодовой базе и попытался сформулировать наши юзейсы для эффектов.
- Во-первых они всё равно используются где-то под капотом collectAsState*. Считается ли это плохой практикой я не уверен. Но без этого, кажется, мы вообще не можем в том месте, где пытаемся связать Composable функцию с каким-то логическим компонентом, например вьюмоделькой, буквально по всех популярных подходах к архитектуре.
- Во-вторых это подписки на всякие Flow, т.к. только внутри эффектов у нас есть скоуп. И всё это можно было бы разрулить где-то в тех же логических компонентах, если бы не нужно было на эти события взаимодействовать с UI или платформенными штуками. Где-то у нас всратые Material апишки типа боттомшитов и снэкбаров, которые ни спрятать ни показать в m2 без корутин нельзя. Где-то нужен активити контекст, например, чтобы другую активити открыть. Где-то у нас под листвой вообще грабли в виде AndroidView, с которым нужно общаться императивно. Где-то приходится заворачивать в это всё пермишны и Result API. И как быть без эффектов то?
- В-третьих это часто используется как колбэк от UI, что он там начал рисоваться, типа "бизнес логика, запускайся". В этом кейсе я согласен, можно это на уровень Composable и не тянуть. С remember я тоже по большей части согласен в продуктовом коде, но когда пишем библиотеку уже не очень. Ребята в аккомпанисте соврать не дадут.
В общем типичный срач между тем, кто пишет инструмент и предполагает как его нужно использовать, и теми кто пытается применить его на практике и борется со всем миром лишь бы оно вообще завелось, и пофиг на то насколько это идеологически чисто. Можно понять обе стороны, но обе не сильно-то и правы. Мы понимаем, что это всё лучше не использовать, если можно обойтись. Нам тоже хотелось бы писать такие Composable функции, которые просто принимали бы уже готовый стейт. Но это невозможно, или с точки зрения существующих библиотек (от других отделов гугла же), или с точки зрения легаси, или с точки зрения перформанса, или просто альтернатива настолько бойлерплейтная, что всему комьюнити проще так.