про Get - завязываться на одну библиотеку плохо. Ок, вон Bloc постоянно меняется, и какая нибудь условная 7 версия совершенно не совместима с 8 и что будет дальше? Ну типа можно остаться на 7 версии. А почему если в Get сломают Get нельзя остаться на той версии которая работает? Ну ок, ты завязался на 10 разных либ, а не на одну. Чем это лучше? Каждая из них может накрыться медным тазом и у тебя так же не будет работать приложение из-за нее, и тебе все равно придется решать этот вопрос. + если ты большая компания, ты можешь позволить себе продолжать развивать тот же Get если вдруг разработчики например от нее откажутся или пойдут другим путем и все сломают... ну типа код открыт. Есть разные варианты.
Когда будет один и тот же пример, но с использование разных подходов - clean arch + bloc, clean arch + getx, и в третьем видео сравнение предыдущих двух подходов?
Вопрос был не про архитектуру приложения в целом, а про "архитектурную либу, которую вы используете", т. е. подразумевались конкретные библиотеки архитектуры представления (Presentation layer), или иными словами - стейт-менеджеры.
В GetX много антипаттернов. Это "God object" в котором намешано всё подряд. Там не используется context, что уже красный флаг. Вы будете сильно привязаны к конкретным реализациям getx и поменять, например i18n или DI будет сложно. Всё привязано к одному пакету, порой намного удобной когда это несколько пакетов. Плюс нельзя убрать не нужные зависимости из production build'а. Кароче, это каша кода которая нарушает хорошие практики и большим проектам даст много боли. На маленькие проекты кому-то сойдёт погамнокодить побыстрому не заморачиваясь. Но мне противно опускаться до такого уровня даже для простого проекта.
Здравствуйте, отправлял вам заявку на стажировку. Ничего пока не ответили. Может я вам не подхожу, но если так, то могли бы хотя бы ответить(
Топ контент! Спасибо большое !
Спасибо за контент, Влад
про Get - завязываться на одну библиотеку плохо. Ок, вон Bloc постоянно меняется, и какая нибудь условная 7 версия совершенно не совместима с 8 и что будет дальше? Ну типа можно остаться на 7 версии. А почему если в Get сломают Get нельзя остаться на той версии которая работает? Ну ок, ты завязался на 10 разных либ, а не на одну. Чем это лучше? Каждая из них может накрыться медным тазом и у тебя так же не будет работать приложение из-за нее, и тебе все равно придется решать этот вопрос. + если ты большая компания, ты можешь позволить себе продолжать развивать тот же Get если вдруг разработчики например от нее откажутся или пойдут другим путем и все сломают... ну типа код открыт. Есть разные варианты.
Спасибо за ролик!
Жаль не затронули вопрос где найти время на всё что говорится с 6:09-14:23, не перегореть и ещё параллельно работать.
" - Как мне найти мотивацию?
- Никак. Оставайтесь в жопе."
1. Наметить план (не жесткий-по ходу выполнения должен корректироваться).
2. Каждый день на его выполнение тратить 1-2 часа
Когда будет один и тот же пример, но с использование разных подходов - clean arch + bloc, clean arch + getx, и в третьем видео сравнение предыдущих двух подходов?
При внедрении гетикса в проект можно забыть про чистую архитектуру :)
@@soonaro это почему же?) разработчик становится говнокодером?)
@@nickkorolev8869 я бы назвал его "повелителем синглтонов" ))
@@soonaro ну а с другой стороны, есть модель и повелитель синглтонов управляет этой моделью :)
у меня кстати есть учебник по дарт/флаттер на русском. Надо?
не могу сказать что он топовый топ, но норм.
Спасибо.
OK!
Вопрос про архитектуру, ответ про блок и прочие Стейт менеджеры. Wtf?
Вопрос был не про архитектуру приложения в целом, а про "архитектурную либу, которую вы используете", т. е. подразумевались конкретные библиотеки архитектуры представления (Presentation layer), или иными словами - стейт-менеджеры.
@@flutterwtf Спасибо за ответ.
Первый!
В GetX много антипаттернов. Это "God object" в котором намешано всё подряд. Там не используется context, что уже красный флаг. Вы будете сильно привязаны к конкретным реализациям getx и поменять, например i18n или DI будет сложно. Всё привязано к одному пакету, порой намного удобной когда это несколько пакетов. Плюс нельзя убрать не нужные зависимости из production build'а. Кароче, это каша кода которая нарушает хорошие практики и большим проектам даст много боли. На маленькие проекты кому-то сойдёт погамнокодить побыстрому не заморачиваясь. Но мне противно опускаться до такого уровня даже для простого проекта.
Влад, sheep-apps и wtf это разные компании?)
Нет 🙂
Не обижайте блок, а то он однажды может обидеть вас!
на русском языке есть книга по флаттеру "Фрэнк Заметти Flutter на практике"
Свят и Глеб это один и тот же человек?
Практически, да 😃
Чуваки, чет вы совсем пропали...