наверное данный подход где-то и нужен в очень крайних случаях, но он ломает архитектуру - компонент не должен ни знать ни управлять внешней средой - среда определяет где и как он будет расположен и с какими свойствами.
в вашем случае розетка, которую я хочу разместить на стене, диктует мне правила где и как ее размещать! во как! а я просто хотел ее воткнуть в стену и так чтобы она не отсвечивала! ))
к сожалению у нас в РФ капиталисты слишком молоды и неопытны - не хватает знаний и опыта старой капиталистической школы.
Реально у нас после 40 найти работу - не реально. Знакомая HR сказала,что негласно у всех новоришей стоит негласное правило - после 40 не рассматривать кандидатов
Мой дядька был крутым инженером-конструктором (почти айтишник). Так вот он мне говорил, что специалист становится настоящим инженером только к годам 40-45, а рассвет творческого потенциала инженера наступает уже около 50-60 лет
Но нашим горе-бизнесменам нужно мясо - проекты заваливают мясом а не знанием и опытом Друг работает в Амстердаме - говорит у них работает дедушка за 60 и даже очень продуктивно. На западе капиталисты умеют считать деньги. К сожалению нашим капиталистам не хватает ни опыта ни мозгов потому как сами еще не дожили до такого возраста
Меня тоже поражает тот факт, что составная часть чистой архитектуры - фича - подается как сама чистая архитектура.
Приложение не может быть фичей по определению! FSD - это отчаянная попытка, тех кто не хотел или не разобрался в чистой архитектуре, иметь хоть какую-то архитектуру пусть даже косую и кривую
ай-яй-яй! как не хорошо логировать очень персональные данные !!! неужели никто вам не говорил что ни в коем случае нельзя в логи писать персональные данные в виде идентификатора пользователя + идентификатор сессии - это прям таки рай какой-то для злоумышленников! )
Логи это не свалка не нужной информации - там должна быть только информация для разбора ошибок - остальной мусор там не нужен! Остальное все - в метрики, которые отображают все что происходит с приложением! Иначе у вас не лог, а помойка в которой очень тяжело найти действительно полезную информацию о том как и почему случился баг или баги
Мне кажется что feature дизайн приложения вполне решает все задачи и не создает проблем с microservice hell.
Фичи можно перекомпоновывать на страницах как хочется но при этом не создается куча микросервисов и не возникает проблем на бэкэнде
Мне кажется что у вас проявился синдром человека с молотком - когда ему после того как он берет в руки молоток все вокруг кажется гвоздями! В вашей ситуации - вы увлеклись микросервисами, создали бОльшую сложность с которой потом героически сражались, но в итоге создали ее новый вид
Увлечение BDUI возвращает на во времена когда часть страницы рендерилась на php на сервере а часть логики нужно было обрабатывать на клиенте - это усложняет процесс разработки привнося гораздо бОльшую сложность - теперь и серверная логика связана с клиентской и это все превращается в клубок зависимостей
Хотелось бы нормальный рассказ с разъяснениями а не просто перевод жаргонов и "приколюх". Читается просто как набор каких-то фраз без связи друг с другом На английском с их жаргоном может и сойдет но на п=русском - билеберда. Перевод не означает же просто закинуть в переводчик - это и переосмысление и пересказ в понятном стиле.... Извините за занудство, но не осилил - бросил читать
Кирилл, ты так много говорил о чистом view и тут на тебе - MobX!!! Это же ярчайший пример антипаттерна когда модель тесно связана с view Любой хороший стейт-менеджер - это уже дело десятое - он расположен глубоко в домене и никак не связан с view или другими слоями архитектуры
А по поводу минималистичности интерфейса - можно посмотреть и на другую библиотеку автора Zustand - Daishi Kato (https://github.com/dai-shi) Valtio, но когда углубляешься в реализацию - понимаешь что за красивый хвост приходится платить .... :)
Александр, возможно вы и правы. Речь идет о том, что я предоставил полное описание реализации Zustand в статье и там всё предельно просто и минималистично: pub / sub объект + один системный хук из React (всего около 2кб текста)
Разбираться во внутренностях реализации MobX нет ни сил ни желания поэтому я условно и назвал ее "магией". Оппоненты все время приводят в качестве аргумента его минималистичный интерфейс, но я же все время ведут речь о реализации ! Интерфейс - это совсем другой вопрос!
Было бы конструктивно со стороны оппонентов приводить преимущества в коде реализации и технологиях, а не в его интерфейсе
За вами и вашими выступлениями слежу давно и с интересом.
Ваш взгляд на то как вы пишете и понимаете код для большинства - радикален. Без сомнений, вы много знаете и умеете, но способ программирования, который вы предлагаете резко выбивается из общего представления. Но все равно когда встречаю ваши материалы - пытаюсь прочесть или послушать.
Посмотрел я и описание и примеры бенчмарков - сходу разобраться что к чему и как их правильно написать - очень сложно. Может вы рассмотрите вариант общения в телеге, где я смогу если нужно что-то рассказать про Zustand а вы составите бенчмарк для него?
Меньше эмоций - больше конструктива! Вам определенно нужно устроиться поработать в крупную компанию, чтобы очень много чего понять и в технологическом плане и в плане культуры общения.
В крупных проектах не важны красивости - важна простота, надежность, понимаемость, простая отлаживаемость и предсказуемость. На маленьких проектах - это не важно, можно хоть левой ногой писать - там можно и всякие красивости со всякими рюшечками использовать
наверное данный подход где-то и нужен в очень крайних случаях, но он ломает архитектуру - компонент не должен ни знать ни управлять внешней средой - среда определяет где и как он будет расположен и с какими свойствами.
в вашем случае розетка, которую я хочу разместить на стене, диктует мне правила где и как ее размещать! во как!
а я просто хотел ее воткнуть в стену и так чтобы она не отсвечивала! ))
к сожалению у нас в РФ капиталисты слишком молоды и неопытны - не хватает знаний и опыта старой капиталистической школы.
Реально у нас после 40 найти работу - не реально. Знакомая HR сказала,что негласно у всех новоришей стоит негласное правило - после 40 не рассматривать кандидатов
Мой дядька был крутым инженером-конструктором (почти айтишник). Так вот он мне говорил, что специалист становится настоящим инженером только к годам 40-45, а рассвет творческого потенциала инженера наступает уже около 50-60 лет
Но нашим горе-бизнесменам нужно мясо - проекты заваливают мясом а не знанием и опытом
Друг работает в Амстердаме - говорит у них работает дедушка за 60 и даже очень продуктивно.
На западе капиталисты умеют считать деньги. К сожалению нашим капиталистам не хватает ни опыта ни мозгов потому как сами еще не дожили до такого возраста
обычно если это некоторый цикл статей в начале каждой статьи размещают ссылки на все
Круто! Молодцы!
Могу судить о проделанной работе на основе своего пэт проекта (https://github.com/budarin/my-tasks, который пока не смог завершить)
Большое спасибо за то , что поделились своим опытом!
Меня тоже поражает тот факт, что составная часть чистой архитектуры - фича - подается как сама чистая архитектура.
Приложение не может быть фичей по определению!
FSD - это отчаянная попытка, тех кто не хотел или не разобрался в чистой архитектуре, иметь хоть какую-то архитектуру пусть даже косую и кривую
ай-яй-яй! как не хорошо логировать очень персональные данные !!!
неужели никто вам не говорил что ни в коем случае нельзя в логи писать персональные данные в виде идентификатора пользователя + идентификатор сессии - это прям таки рай какой-то для злоумышленников! )
Логи это не свалка не нужной информации - там должна быть только информация для разбора ошибок - остальной мусор там не нужен! Остальное все - в метрики, которые отображают все что происходит с приложением! Иначе у вас не лог, а помойка в которой очень тяжело найти действительно полезную информацию о том как и почему случился баг или баги
А почему не подошел JSON RPC?
в нем все вами перечисленные проблемы решены by design
Мне кажется что feature дизайн приложения вполне решает все задачи и не создает проблем с microservice hell.
Фичи можно перекомпоновывать на страницах как хочется но при этом не создается куча микросервисов и не возникает проблем на бэкэнде
Мне кажется что у вас проявился синдром человека с молотком - когда ему после того как он берет в руки молоток все вокруг кажется гвоздями!
В вашей ситуации - вы увлеклись микросервисами, создали бОльшую сложность с которой потом героически сражались, но в итоге создали ее новый вид
Увлечение BDUI возвращает на во времена когда часть страницы рендерилась на php на сервере а часть логики нужно было обрабатывать на клиенте - это усложняет процесс разработки привнося гораздо бОльшую сложность - теперь и серверная логика связана с клиентской и это все превращается в клубок зависимостей
как же интересно у вас там!!!
у меня скукотища - последняя всегда всех побеждает, а я - тряпка не сопротивляюсь даже - бесполезно )
Прочитав статью осознал, что я дофаминовый наркоман ...
Статья очень полезная я бы поставил плюс за такое прозрение, но токсики украли всю мою карму )
нужно уточнить:
в строгом режиме значение this для глобального объекта windows равно undefined
var o = {
name: 'myObject',
getName: function getName(){ return this.name }
}
window.name = 'lalala';
window.getName = o.getName
console.log(window.getName()) // VM294:6 Uncaught TypeError: Cannot read properties of undefined (reading 'name')
Хотелось бы нормальный рассказ с разъяснениями а не просто перевод жаргонов и "приколюх". Читается просто как набор каких-то фраз без связи друг с другом На английском с их жаргоном может и сойдет но на п=русском - билеберда. Перевод не означает же просто закинуть в переводчик - это и переосмысление и пересказ в понятном стиле....
Извините за занудство, но не осилил - бросил читать
Отлично, вопрос отпадает - видно я не так понял контекст упоминания его.
Просто я у же начал переживать, что происходит смешивания концепций
Кирилл, ты так много говорил о чистом view и тут на тебе - MobX!!!
Это же ярчайший пример антипаттерна когда модель тесно связана с view
Любой хороший стейт-менеджер - это уже дело десятое - он расположен глубоко в домене и никак не связан с view или другими слоями архитектуры
ну если та часть что отвечает за работу с React вам не интересна, вторая часть, что работает везде без реакта - это чистый pub/sub
А по поводу минималистичности интерфейса - можно посмотреть и на другую библиотеку автора Zustand - Daishi Kato (https://github.com/dai-shi) Valtio, но когда углубляешься в реализацию - понимаешь что за красивый хвост приходится платить .... :)
Вообще рекомендую Daishi Kato (https://blog.axlight.com/) - он автор нескольких типов state-manages
Александр, возможно вы и правы. Речь идет о том, что я предоставил полное описание реализации Zustand в статье и там всё предельно просто и минималистично: pub / sub объект + один системный хук из React (всего около 2кб текста)
Разбираться во внутренностях реализации MobX нет ни сил ни желания поэтому я условно и назвал ее "магией". Оппоненты все время приводят в качестве аргумента его минималистичный интерфейс, но я же все время ведут речь о реализации ! Интерфейс - это совсем другой вопрос!
Было бы конструктивно со стороны оппонентов приводить преимущества в коде реализации и технологиях, а не в его интерфейсе
Дмитрий, очень рад пообщаться с вами!
За вами и вашими выступлениями слежу давно и с интересом.
Ваш взгляд на то как вы пишете и понимаете код для большинства - радикален. Без сомнений, вы много знаете и умеете, но способ программирования, который вы предлагаете резко выбивается из общего представления. Но все равно когда встречаю ваши материалы - пытаюсь прочесть или послушать.
Посмотрел я и описание и примеры бенчмарков - сходу разобраться что к чему и как их правильно написать - очень сложно. Может вы рассмотрите вариант общения в телеге, где я смогу если нужно что-то рассказать про Zustand а вы составите бенчмарк для него?
Хорошо я посмотрюи при наличии времени добавлю код
( Было бы хорошо если бы вы какое-нибудь описание дали по данному бенчмарку )
сразу нужно предупреждать что вы технологический ортодокс и экстремист, чтобы не связываться и не тратить зря силы и нервы :)
я вам говорю о внутреннем устройстве, а вы мне только якобы красивую сверкающую обертку показываете!!!
ЗЫ: Раневская как-то сказала: за каждым красивым хвостом фазана прячется обыкновенная жопа :)
Меньше эмоций - больше конструктива!
Вам определенно нужно устроиться поработать в крупную компанию, чтобы очень много чего понять и в технологическом плане и в плане культуры общения.
В крупных проектах не важны красивости - важна простота, надежность, понимаемость, простая отлаживаемость и предсказуемость. На маленьких проектах - это не важно, можно хоть левой ногой писать - там можно и всякие красивости со всякими рюшечками использовать