Женя, привет. Это круто. Не могу не написать тебе свой восторг! Я на 25 минуте попал в ступор с вопросом Зачем!??? И ты тут же на него ответил!!! Это уровень бога в понимании! Спасибо. Я знаю о чем говорю, у меня такое есть когда я хапкидо преподаю. Ты словно маг и мы смотрим на тебя и ты знаешь наперед все наши мысли...
Начал понимать этот урок только с 4-ого просмотра и после того как пытался сам потыкать. Сложная и важная тема. Спасибо за такое подробное разъяснение.
Прикольно! Я этого не знал вообще, несмотря на то, что уже написал пару приложух. Но по первым двум минутам, стало ясно, что это как-раз про то, что делает мой любимый Provider )
@@LearnDartFlutter Ну провайдер облегчает работу с этим, про провайдер написано "A wrapper around InheritedWidget to make them easier to use and more reusable." А еще это топовый пакадж на паб.дев (вообще именно первый в топе), поэтому разобраться и запилить видос по такому важному пакету обязательно нужно ) ну всё-равно же придется, что-то юзать для управления состоянием, раньше вот был bloc, олдфаги флаттера за него топят, но он сложней чем провайдер для новичков. В провайдере нужно просто правильно архитектуру прописывать и всё будет ок, а так, он позволяет легко забыдлокодиться на уровне 9-го класса и всё будет тоже работать, до какой-то степени )) Ты просто, судя по моим ощущениям, самые профессиональные видео снимаешь на тему Флаттера спасибо, что взялся за это. Было бы очень круто, если бы ты показал, как правильно Провайдер юзать, с твоей профессиональной точки зрения. Это было-бы бесценное видео и просмотров будет много, судя по тому, что это важный топовый пакедж.
уроки - бомба. С первого урока смотрю. Но вот сейчас я встрял конкретно. 3 дня пересматриваю. На 3 день понял хоть что-то, но для меня пока это ооочень сложно(
@@VladimirOnokhov В следующих уроках постоянно задействуют инхериты. Поэтому постепенно стало понятнее. Главное, духом не падать и всё получится. Удачи в изучении!
сложно, очень сложно если бы мы знали что это такое мы не знаем что это такое. Мы конечно при своей необразованности можем даже предположить что это диверсия какая то . ❤ спасибо за видео
В примере с InheritedNotifier, метод build вызывается также и у TextField'ов и у ElevatedButton, потому что везде подписывались на изменения инхерита этой строкой: SimpleCalcWidgetProvider.of(context), которая содержит в себе -> context.dependOnInheritedWidgetOfExactType(); Как мы знаем dependOnInheritedWidgetOfExactType получает и подписывается на инхерит. Я решил данную проблему с помощью getElementForInheritedWidgetOfExactType, который позволяет только получить инхерит. 1) Создал статический метод getProvider со следующим кодом: static SimpleCalcWidgetProvider? getProvider(BuildContext context) { final element = context .getElementForInheritedWidgetOfExactType(); final provider = element?.widget as SimpleCalcWidgetProvider; return provider; } 2) Заменил у TextField'ов и у ElevatedButton вызов .of на .getProvider P.s. Может быть я что-то пропустил, просматривая видео, и моя надстройка бессмысленна, но я новичок, мне простительно :3. Если это неправильно, поправьте пожалуйста.
Спасибо за урок, очень понятно и наглядно, только твои уроки помогают. Подскажи где найти снипеты для быстрого создания инхерит класа или возможно как создать свой шаблон....
Привет, отличный контент, большое спасибо за проделанную работу!!! Подскажи, почему глобальные данные с архитектурной точки зрения - это плохо? (может есть хорошая статья на эту тему). Относится ли к глобальным данным глобальный стейт (например, flux подход)? Я пришел во флаттер с веб разработки и мне кажется неудобным то, что используя провайдер или блок для управления стейтом, стейт получается намертво "встроенным" в дерево. Вместо того, чтобы он был как бы над всем приложением. Как в том же redux mobx. Может я просто не до конца разобрался еще...
Проще было бы использовать Equitable для модели. Тогда можно было бы убрать наследование модели от ChangeNotifier и момент с didchangedependencies, что сильно бы всё упростило. Ну и полезно было бы показать связку стейтфул+инхеритед, чтобы и жизненный цикл был и O(1) поиска.
Видос клевый но есть вопрос. didChangeDependencies - собственно искал как этот метод работает. и подозреваю что вызывается может не 1 раз, в отличие от initState
Вопрос по InheritedNotifier. В корневом виджете мы создаем объект _model. Потом как параметр передаем _model в InheritedNotifier, где тоже ее запоминаем как переменную уже этого объекта. Получается мы в 2-х местах храним _model, и еще как параметр супер-классу передаем. Это нормально, не будет тут никаких коллизий?
@@LearnDartFlutter честно не знаю. Возможно плохая идея хранить экземпляры в разных объектах со своими жизненными циклами. Собственно и хотел узнать ответ на свой вопрос. Нет тут опасностей?
Посмотрел видос понял чего там дженерик не вписался Из за static им же изолируешь от среды класса метод не может определить тип в методе статик у Т конструкция получается следующая чтобы работала нужно дать компилятору больше данных о типе модели с которым работает провайдер, код такой вот получается class ChangeNotifierProvaider extends InheritedNotifier { final Model model; const ChangeNotifierProvaider( {super.key, required super.child, required super.notifier, required this.model}); static M? of( BuildContext context) { return context.dependOnInheritedWidgetOfExactType()?.model as M; } }
26:13 "по поводу многословности " строки 80--84 и .... 29:33 строки 80-92 , и в чем фишка? , в том что дженерик можем потом еще использовать в другом месте?? или чтото другое? суть понял как сделать, а каков выхлоп от этого не уловил. Сорян.
@@LearnDartFlutter 1:35:00 Код функции не возвращает значение: if (provider != null) { provider.model as T;} else {return null;} Получается, что при срабатывании условия функция ничего не возвращает.
Спасибо за контент, сравни пожалуйста swift и flutter в плане сложности освоения и написания приложений. То что UIKit намного сложнее чем flutter а SwiftUI менее сложен я понимаю, но возможно ты что то более конкретное можешь рассказать.
@@LearnDartFlutter Посмотрел видос понял чего там дженерик не вписался Из за static им же изолируешь от среды класса метод не может определить тип в методе статик у Т конструкция получается следующая чтобы работала нужно дать компилятору больше данных о типе модели с которым работает провайдер, код такой вот получается class ChangeNotifierProvaider extends InheritedNotifier { final Model model; const ChangeNotifierProvaider( {super.key, required super.child, required super.notifier, required this.model}); static M? of( BuildContext context) { return context.dependOnInheritedWidgetOfExactType()?.model as M; } }
Чет перемудрил с примером по моему. Не совсем понятно почему в didChangeDependency почему не в init? didChangeDep тоже вызывается потенциально более одного раза? В общем не понятно с didChange.. когда конкретно он срабатывает)
Главное отличие didChangeDependency от onInit, в том, что didChangeDependency вызывается так же один раз, но чуть позже onInit, и в нем уже есть context. А в onInit его еще нет.
Why to use getElementForInheritedWidgetOfExactType in order just to observe the value(get the inherited Widget, cast to myInherited one, then apply to the value, when you can just envoke getInheritedWidgetOfExactType and at once obtain value. Who can explain me this ?
А если просто написать компаратор для SimpleCalcWidgetModel то ведь функция updateShouldNotify у InheritedWidget должна сработать? Тогда и не надо было бы переобразовывать ResultWidget в stateful. Разве не так? Или я что-то недопонимаю 🤷🏻♂
Пожалуйста ответьте кто разбирается, разве в примере где автор разбирал InheritedNotifier он не обновлял все виджеты которые подписаны на инхерит? Тогда какой смысл от этого инхерита если он обновил и текст филды и кнопку и результат
I wanted to talk about it. It seems that all childrens' build methods is called, I also check them using debug tool. So, if the initial problem was the fact that it updates not necessarily widgets, it still do the same
честно - ни чер-та не понятно, буду пересматривать и читать доки -- upd я понимаю, зачем они нужны - не перебилживать каждый раз все виджеты ради изменения данных или состояний вместо это юзать специальные штуки - инхериты, которые помогают наследовать и передавать инструкции к обновлению только того, тех состояний, которыми мы хотим управлять в конкретном сценарии но я не понимаю, как эту всю фигню писать, не понимаю сам синтаксис и цепочку последовательности написания. видимо надо какие-то простые упражнения выполнить на практике или в микро-проекте
Ты был прав. Это видео за один раз не пересмотреть и за два тоже))
посмотреть!!!
Женя, привет. Это круто. Не могу не написать тебе свой восторг! Я на 25 минуте попал в ступор с вопросом Зачем!??? И ты тут же на него ответил!!! Это уровень бога в понимании! Спасибо. Я знаю о чем говорю, у меня такое есть когда я хапкидо преподаю. Ты словно маг и мы смотрим на тебя и ты знаешь наперед все наши мысли...
Начал понимать этот урок только с 4-ого просмотра и после того как пытался сам потыкать. Сложная и важная тема. Спасибо за такое подробное разъяснение.
ВСЁ ПО ПОЛОЧКАМ. Уроки просто топ. Полуторачасовой видео на одном дыхании.
Спасибо за курс, посмотрел все ваши видео, самое тяжелое видео для моего понимания было это видео.
Спасибо большое, без ваших уроков не представляю изучение Flutter, просто не могу выразить словами как ваши уроки мне помогают, спасибо вам за Все !
Прикольно! Я этого не знал вообще, несмотря на то, что уже написал пару приложух. Но по первым двум минутам, стало ясно, что это как-раз про то, что делает мой любимый Provider )
провайдер это просто немного заготовок для инхерита и знать это нужно)
@@LearnDartFlutter Ну провайдер облегчает работу с этим, про провайдер написано "A wrapper around InheritedWidget to make them easier to use and more reusable." А еще это топовый пакадж на паб.дев (вообще именно первый в топе), поэтому разобраться и запилить видос по такому важному пакету обязательно нужно )
ну всё-равно же придется, что-то юзать для управления состоянием, раньше вот был bloc, олдфаги флаттера за него топят, но он сложней чем провайдер для новичков. В провайдере нужно просто правильно архитектуру прописывать и всё будет ок, а так, он позволяет легко забыдлокодиться на уровне 9-го класса и всё будет тоже работать, до какой-то степени ))
Ты просто, судя по моим ощущениям, самые профессиональные видео снимаешь на тему Флаттера спасибо, что взялся за это. Было бы очень круто, если бы ты показал, как правильно Провайдер юзать, с твоей профессиональной точки зрения. Это было-бы бесценное видео и просмотров будет много, судя по тому, что это важный топовый пакедж.
Благодаря вам я нашел работу, спасибо!
Пока самое сложное из того что прошел) Но так даже интереснее!
Спасибо за видео!👍 Смотрел несколько часов, тяжело далось)
Спасибо большое за подробное объяснение Flutter! У Вас лучшие уроки по Flutter!
Только читал про них и тут опа, видосик. Спасибо большое за ваш труд!!!
спасибо! понял теперь для чего const нужен ))
уроки - бомба. С первого урока смотрю. Но вот сейчас я встрял конкретно. 3 дня пересматриваю. На 3 день понял хоть что-то, но для меня пока это ооочень сложно(
тоже самое... как у тебя сейчас обстоят дела с этим?
@@VladimirOnokhov В следующих уроках постоянно задействуют инхериты. Поэтому постепенно стало понятнее. Главное, духом не падать и всё получится. Удачи в изучении!
@@burbon___7118 спасибо, что ответил. и тебе тоже удчаи!
Харе Кришна 🙏😌 со второго просмотра что-то стало доходить)
сложно, очень сложно если бы мы знали что это такое мы не знаем что это такое. Мы конечно при своей необразованности можем даже предположить что это диверсия какая то .
❤ спасибо за видео
Спасибо большое! было полезно и познавательно.
Спасибо большое. Очень полезное видео.
Спасибо, супер полезная инфа!
В примере с InheritedNotifier, метод build вызывается также и у TextField'ов и у ElevatedButton, потому что везде подписывались на изменения инхерита этой строкой:
SimpleCalcWidgetProvider.of(context), которая содержит в себе -> context.dependOnInheritedWidgetOfExactType();
Как мы знаем dependOnInheritedWidgetOfExactType получает и подписывается на инхерит.
Я решил данную проблему с помощью getElementForInheritedWidgetOfExactType, который позволяет только получить инхерит.
1) Создал статический метод getProvider со следующим кодом:
static SimpleCalcWidgetProvider? getProvider(BuildContext context) {
final element = context
.getElementForInheritedWidgetOfExactType();
final provider = element?.widget as SimpleCalcWidgetProvider;
return provider;
}
2) Заменил у TextField'ов и у ElevatedButton вызов .of на .getProvider
P.s. Может быть я что-то пропустил, просматривая видео, и моя надстройка бессмысленна, но я новичок, мне простительно :3. Если это неправильно, поправьте пожалуйста.
Мощно! Спасибо за видео! 🤝
Спасибо вам за большой урок
you are number one blogger
Хороший урок. Бомба
Спасибо Евгений, как всегда ТОП
Согласен
Спасибо за видео! Я попробовал: корневой SimpleCalcWidget тоже может быть StatelessWidget (в варианте с InheritedNotifier).
Прочитал на хабре не до конца догнал , но тут прям всё четко )
Спасибо за урок, очень понятно и наглядно, только твои уроки помогают.
Подскажи где найти снипеты для быстрого создания инхерит класа или возможно как создать свой шаблон....
Есть расширение для vscode. Awesome flutter snippets
@@LearnDartFlutter Понял спасибо, только я android studio пользуюсь. Вы бы посоветовали перейти на VS code ? Есть какая нибудь существиная разница?
@@lifewear.reseller для студии тоже есть какой то плагин кажется
третий раз возвращаюсь к видосу
Спасибо!! !
Good lesson 👍🏻
Привет, отличный контент, большое спасибо за проделанную работу!!! Подскажи, почему глобальные данные с архитектурной точки зрения - это плохо? (может есть хорошая статья на эту тему). Относится ли к глобальным данным глобальный стейт (например, flux подход)?
Я пришел во флаттер с веб разработки и мне кажется неудобным то, что используя провайдер или блок для управления стейтом, стейт получается намертво "встроенным" в дерево. Вместо того, чтобы он был как бы над всем приложением. Как в том же redux mobx. Может я просто не до конца разобрался еще...
Это очень долгий разговор для комментария, но редакс нормально использовать
Проще было бы использовать Equitable для модели. Тогда можно было бы убрать наследование модели от ChangeNotifier и момент с didchangedependencies, что сильно бы всё упростило. Ну и полезно было бы показать связку стейтфул+инхеритед, чтобы и жизненный цикл был и O(1) поиска.
Ютюб большой, можно записать свой туториал, велком)
@@LearnDartFlutter у меня нет твоего таланта учителя, а уж как велика моя лень...
Женя вопрос, как сделать шаблоны, для создания виджетов как у тебя?
Поддерживаю вопрос
надо снипеты настраивать, в телегу напишите, я файл скину.
инхериты мощь!!!
Приветствую! А почему бы не унаследовать провайдер от генерика ?
можно унаследовать
Видос клевый но есть вопрос. didChangeDependencies - собственно искал как этот метод работает. и подозреваю что вызывается может не 1 раз, в отличие от initState
Все понятно, но нужно все опробовать ручками.
Вопрос по InheritedNotifier. В корневом виджете мы создаем объект _model. Потом как параметр передаем _model в InheritedNotifier, где тоже ее запоминаем как переменную уже этого объекта.
Получается мы в 2-х местах храним _model, и еще как параметр супер-классу передаем.
Это нормально, не будет тут никаких коллизий?
А какие коллизии там могут появится?
@@LearnDartFlutter честно не знаю. Возможно плохая идея хранить экземпляры в разных объектах со своими жизненными циклами.
Собственно и хотел узнать ответ на свой вопрос.
Нет тут опасностей?
Посмотрел видос понял чего там дженерик не вписался Из за static им же изолируешь от среды класса метод не может определить тип в методе статик у Т конструкция получается следующая чтобы работала нужно дать компилятору больше данных о типе модели с которым работает провайдер, код такой вот получается
class ChangeNotifierProvaider
extends InheritedNotifier {
final Model model;
const ChangeNotifierProvaider(
{super.key,
required super.child,
required super.notifier,
required this.model});
static M? of(
BuildContext context) {
return context.dependOnInheritedWidgetOfExactType()?.model as M;
}
}
реально понять такие штуки сложно. не знаю сколько раз смотрел
26:13 "по поводу многословности " строки 80--84 и .... 29:33 строки 80-92 , и в чем фишка? , в том что дженерик можем потом еще использовать в другом месте?? или чтото другое?
суть понял как сделать, а каков выхлоп от этого не уловил. Сорян.
В конце в статичной функции of нет return. Есть return null, но нет return provider.model as T;
ничего не понял
@@LearnDartFlutter 1:35:00 Код функции не возвращает значение: if (provider != null) { provider.model as T;} else {return null;} Получается, что при срабатывании условия функция ничего не возвращает.
@@ПавелШистеров и правда, я это пропустил, но позже в видео я таки напишу этот дженерик)
Спасибо за контент, сравни пожалуйста swift и flutter в плане сложности освоения и написания приложений. То что UIKit намного сложнее чем flutter а SwiftUI менее сложен я понимаю, но возможно ты что то более конкретное можешь рассказать.
Там нет никакой принципиальной разницы в освоении)
@@LearnDartFlutter
Посмотрел видос понял чего там дженерик не вписался Из за static им же изолируешь от среды класса метод не может определить тип в методе статик у Т конструкция получается следующая чтобы работала нужно дать компилятору больше данных о типе модели с которым работает провайдер, код такой вот получается
class ChangeNotifierProvaider
extends InheritedNotifier {
final Model model;
const ChangeNotifierProvaider(
{super.key,
required super.child,
required super.notifier,
required this.model});
static M? of(
BuildContext context) {
return context.dependOnInheritedWidgetOfExactType()?.model as M;
}
}
Чет перемудрил с примером по моему. Не совсем понятно почему в didChangeDependency почему не в init? didChangeDep тоже вызывается потенциально более одного раза? В общем не понятно с didChange.. когда конкретно он срабатывает)
...кроме того, следует отметить, что initstate вызывается перед сборкой, и в этот момент контекст недоступен.
Кстати, хороший вопрос, у меня тоже возник
Главное отличие didChangeDependency от onInit, в том, что didChangeDependency вызывается так же один раз, но чуть позже onInit, и в нем уже есть context. А в onInit его еще нет.
Why to use getElementForInheritedWidgetOfExactType in order just to observe the value(get the inherited Widget, cast to myInherited one, then apply to the value, when you can just envoke getInheritedWidgetOfExactType and at once obtain value. Who can explain me this ?
А если просто написать компаратор для SimpleCalcWidgetModel то ведь функция updateShouldNotify у InheritedWidget должна сработать? Тогда и не надо было бы переобразовывать ResultWidget в stateful. Разве не так? Или я что-то недопонимаю 🤷🏻♂
Я уже не очень помню о чем там урок, можно больше информации?)
Пожалуйста ответьте кто разбирается, разве в примере где автор разбирал InheritedNotifier он не обновлял все виджеты которые подписаны на инхерит? Тогда какой смысл от этого инхерита если он обновил и текст филды и кнопку и результат
I wanted to talk about it. It seems that all childrens' build methods is called, I also check them using debug tool. So, if the initial problem was the fact that it updates not necessarily widgets, it still do the same
Хотите сэкономить время? Начинайте смотреть с 1:20:00
Народ, слушайте 1,25x, будет сразу хорошо усваиваться.
Хорошая шутка))
на х2 даже слушать не надо инфа сразу попадает к вам в мозг
OK!
начиная с нотифаера я поплыл
T должен экстендить Listeneble, а не ChangeNotifier(Fox)
честно - ни чер-та не понятно, буду пересматривать и читать доки
--
upd
я понимаю, зачем они нужны - не перебилживать каждый раз все виджеты ради изменения данных или состояний
вместо это юзать специальные штуки - инхериты, которые помогают наследовать и передавать инструкции к обновлению только того, тех состояний, которыми мы хотим управлять в конкретном сценарии
но я не понимаю, как эту всю фигню писать, не понимаю сам синтаксис и цепочку последовательности написания. видимо надо какие-то простые упражнения выполнить на практике или в микро-проекте
вышло разобраться? можете поделиться опытом как совладать с информацией которую дали в видосе?))
@@morrigan_ghostа как у вас? вышло?
1:37:17 Евгений пошутил на счёт блокировки ютуба, тогда это казалось невероятным, но сейчас уже не смешно.
это ад
"большая табличка" 18:29 это какой урок?
Ты о чем?
@@LearnDartFlutter вы в это время показываете таблицу.... оно с какого вашего урока???
@@faizulla5838 так наверное с этого раз тут показываю, но вообще я не помню, видео пол года назад если не больше записывал)
37:48
У меня не грузит карту на бусти, бесконечная загрузка и все
наверное можно попробовать ещё раз
@@LearnDartFlutter не один раз пробовал, просто не грузит и все
cakchanhamay
Flutter ето вообще дь|мящая куча ненужного кода
ты просто не понял всю мощь флатера
Спасибо!