Еще один красный флаг - недавно проходил собеседование - тех собеседование проводил "типа сеньор" в том стеке, на который шел. ХР расхваливал какие они профессионалы, какие крутые специалисты у них в команде, как многому я смогу у них научиться. "Сеньор" "валил" "глубокими" вопросами - на половину ответил, на половину не смог (ну, не надо это в повседневной работе). Но в один момент в процессе беседы он сам валится на том, что не знает, то что знает изучающий этот стек во второй день, ну, и в другом моменте путает с другим стеком...... Спрашивается что это было? "Интернет-сеньор" )? А по факту то ли сознательно они все обманывают, то ли "сеньор" там всех "водит за нос".
Почему при разводе супруг требует половину нажитого во время брака, хотя один занимался бизнесом, а второй домохозяйством? Это нормально, что обычная домохозйка требует половину состояния успешного миллионера? Вообще, все это, на мой взгляд, вопросы со звездочкой.....
Т.е. вы предлагаете, чтобы объект User знал об объекте UserDto? (И в случае изменения объекта UserDto нам надо помнить, что надо поправить методы в User (User2, User3 и т.п....)?)
А если следовать букве закона — разве должны?
В статье же написано: «Пояснение PDA: «… в качестве ответчика по прошедшему делу были указаны не мы, а КлаудФлэр, Инк, соответственно у нас не было никакой информации об этой ситуации. То есть решение мы получили «по факту» и возможности повлиять на происходящее отсутствовала».»
Да — все тривиально. На глубину данная заметка не претендует. «Ушел в цикл» в асинхронной функции и всё «встало».
Просто, как и писал в начале, столкнулся с тем, что по-началу многие разработчики слишком много надежд возлагают на асинхронные функции и ждут от них, того, чего не стоит.
И, буквально, на следующий день появилась с технической точки зрения гораздо более глубокая статья — habr.com/ru/company/ligastavok/blog/539782 — достаточно интересно почитать. И вот еще интересная статья «по-теме» — habr.com/ru/post/532862.
Лучше всего использовать, то, что лучше в вашем случае. BLoC, вероятно, на данный момент самая простейшая архитектура (концепция), которая может быть реализована разными инструментами (в том числе и Provider-ом). Provider всего лишь удобный инструмент, позволяющий получить доступ к чему-то на разных уровнях дерева виджетов. Не думаю, что стоит противопоставлять их. В библиотеке flutter_bloc используется Provider. Самый простой вариант (если прям совсем «теряетесь») попытаться начать писать с использованием архитектуры BloC (инструмент — Provider либо flutter_bloc ), а там дальше сами увидите в какую сторону «вырастет». Главное во всем этом разнообразии подходов — четко разделить интерфейс и бизнес-логику.
ну, не всегда. Я правда про российскую компанию, но получил фидбэк уже постфактум, причем явно по моему заданию.
Еще один красный флаг - недавно проходил собеседование - тех собеседование проводил "типа сеньор" в том стеке, на который шел. ХР расхваливал какие они профессионалы, какие крутые специалисты у них в команде, как многому я смогу у них научиться. "Сеньор" "валил" "глубокими" вопросами - на половину ответил, на половину не смог (ну, не надо это в повседневной работе). Но в один момент в процессе беседы он сам валится на том, что не знает, то что знает изучающий этот стек во второй день, ну, и в другом моменте путает с другим стеком...... Спрашивается что это было? "Интернет-сеньор" )? А по факту то ли сознательно они все обманывают, то ли "сеньор" там всех "водит за нос".
Я бы не был таким однозначным - а что, если бы этот супруг не доверился успешному бизнесмену и вместо забот по домохозяйству тоже мог сделать карьеру?
Почему при разводе супруг требует половину нажитого во время брака, хотя один занимался бизнесом, а второй домохозяйством? Это нормально, что обычная домохозйка требует половину состояния успешного миллионера? Вообще, все это, на мой взгляд, вопросы со звездочкой.....
Просто пытаются "прогнуть" - прокатит/не прокатит...
А мне flutter_bloc больше "загтовку" для MVI напоминает...
Интересно, а вы по поводу чего судились? А как же лодки/яхты, которые, вроде, всегда недвижимостью были...
Т.е. вы предлагаете, чтобы объект User знал об объекте UserDto? (И в случае изменения объекта UserDto нам надо помнить, что надо поправить методы в User (User2, User3 и т.п....)?)
В статье же написано: «Пояснение PDA: «… в качестве ответчика по прошедшему делу были указаны не мы, а КлаудФлэр, Инк, соответственно у нас не было никакой информации об этой ситуации. То есть решение мы получили «по факту» и возможности повлиять на происходящее отсутствовала».»
Просто, как и писал в начале, столкнулся с тем, что по-началу многие разработчики слишком много надежд возлагают на асинхронные функции и ждут от них, того, чего не стоит.
И, буквально, на следующий день появилась с технической точки зрения гораздо более глубокая статья — habr.com/ru/company/ligastavok/blog/539782 — достаточно интересно почитать. И вот еще интересная статья «по-теме» — habr.com/ru/post/532862.