База у каждого своя. Кто то спрашивает чем отличается var от let во всех подробностях, кто то про микро и макротаски, а по большому счету это все ***ня собачья а не база.
Большинство собесов в РФ как экзамен - тупая зубрежка, спрашивают много того, что забудется через пару недель, и готовиться к нему как к экзамену. Если нужно к собесу дополнительно готовиться, работая по 8 часов день по специальности, значит это плохой собес.
Так не мой, а мейнтейнера redux) Я в его issue скинул сразу свой PR с фиксом, он его проигнорил и протащил такую же правку через своего знакомого, через пол года.
Похожая история была с моим PR и react, вот только никто вслух не сказал из за чего не хотят мержить, и через пол года знакомый мейнтейнера redux, которому я скинул этот ПР, создал точно такой же, только хуже (без тестов) и его протащили мгновенно.
А чем плоха просто папка с json файлами ответов, которые возвращаются в апи методах вместо fetch к серверу, с задержкой, и которую можно использовать в тестах, не поднимая никаких серверов?
Во флаттере абсолютно невозможно написать нетипизированный код
А за код, как в Вашем примере, я программистов бью по рукам
Я привел пример где нельзя типизировать, в ответ это. Слив зачитан.
Ибо что он делает и с какими типами данных работает, должно быть очевидно при беглом взгляде
не должно быть необходимости писать к нему комментарии длиннее самого кода
Комментарии здесь исключительно для вас, тех кто с пеной у рта доказывал бы что "строки это ужас, не проверяются в рантайме" и тп ерунду.
Типы все видны в среде разработки, учите матчасть потом спорьте. Больше настолько очевидные вещи объяснять не буду.
Почему его [интерфейс] не использовать вместо невнятных юнионов
Потому что юнион строже типизирует и не создает дополнительные прослойки типов чем сильно упрощает код, без оверинжиниринга, который в большинстве случаев делает только хуже. И многим не понять пока не попользуются, к сожалению.
неужели Вы думаете, что команда, которая за год довела до релиза весьма непростое приложение ... не в состоянии была разобраться с премудростями RN
Судя по тому что я пишу на RN уже много лет и проблем не имею, видится что не смогла. Хотя скорей дело в лиде, который принял некомпетентное решение, которое уже принесло проблемы и еще аукнется в будущем.
А то, что RN в принципе позволил написать тот говнокод, с которым нам пришлось бороться
Ну Flutter то конечно не позволяет писать говнокод))) С тем же успехом можно написать бесполезную статью как переписывали падающий говнокод с <любая технология> на <любая технология>.
Но флаттер – весьма добротный и качественный инструмент, который как минимум, не хуже, а по моему мнению, так и лучше
Я привел множество примеров почему он хуже, и я бы никогда не выбрал его в 2024 году как инструмент разработки. Но если вы сделали такой выбор, удачи вам.
Тем кто способен только верить - религия. Компетентные выбирают умом.
Очередное голословие. Пример можно?
Дженерики в Дарт есть
Никто не спорит что их нет, но в TS намного больше возможностей типизации, а более строгая типизация - меньше ошибок в коде на этапе выполнения, быстрее разработка из за autocomplete и автоматическая "документация". Взять к примеру RRC, во флаттере абсолютно невозможно полностью типизировать код типа:
// result здесь в зависимости от параметра query, здесь - User (для ненормализованной версии)
// значение query проверяется компилятором, это union type
const [{result, loading, error}, fetchUser] = useQuery({
query: 'getUser',
params: userId
})
// user здесь в зависимости от typename - в данном случае User
// значение typename проверяется компилятором - это union type
const user = useSelectEntityById(userId, 'users')
Юнионы же – ИМХО костыль
Они используются во всех опенсорс проектах от крутых технологических компаний типа Microsoft и др, как и в моем коде, и используются не зря. И код выше тому доказательство - они куда компактнее и читаемее чем те же enum. С такими заявлениями стало понятно что в TS вы совсем не разбираетесь.
Не могу не признать, флаттер тоже не свободен от этой проблемы
Вот именно, и чем больше будет библиотек на флаттере, тем больше будет таких проблем, так как новички любят бездумно добавлять библиотеки чтобы "сложить два плюс два". Решение везде одинаковое - строго следить что добавляешь в проект, минимизировать нативные библиотеки.
Почитал ваше статью - серьезное преимущество это видимо потратить кучу денег компании на внедрение BDUI из за неудачного выбора технологии. Добавил там более подробный комментарий.
Dart хуже тк провоцирует писать в неудачном, устаревшем ООП стиле (это отдельный разговор), куда более многословный для одного и того же кода, особенно для функционального стиля, система типов TS это вообще шедевр по сравнению в Dart - Union type, generics и мн.др., наличие лучших фреймворков и библиотек, линтеров и тп.
Больше звучит как оправдание тимлида за неудачно выбранную технологию - про производительность скромно умолчали, но добавилась проблема отсутствия быстрых обновлений и следовательно костыль в виде BDUI.
А самая распространенная проблема в RN - бездумное добавление множества некачественных нативных зависимостей. Когда на флаттере появится столько же мусорных сторонних пакетов, "очумелые ручки" начнут их добавлять и там. Решение - минимум зависимостей, особенно нативных. А те что добавляются - тщательно анализируются, хотя бы по количеству issue и их поддержке. Работает кстати для любой технологии.
Нет ни одной нормальной причины выбрать Flutter вместо React Native. Dart намного хуже TS, фреймворк хуже React, линтеры хуже, популярность сильно меньше чем React + TS, доступность (accessibility) хуже чем у React Native Web, система лейаутов у RN flex, как и в вебе. С новой архитектурой RN производительность больше не проблема, хотя и раньше не особо была проблемой. Проекты крутые на RN на слуху, в том числе от самих Facebook - и это крайне важно с точки зрения будущей поддержки, у Flutter все грустно, гугл его забросил и не использует. Мусор.
Важный момент не проговорен - если сэкономленные деньги не доплачивать за кредит, а внести на депозит / инвестировать / купить крипту, при равной доходности и проценте за вклад это равносильно доплате, но еще и дополнительная подушка безопасности.
Я как то отговорил товарищей переписывать nodejs на go, просто рассказав что nodejs нужно запускать в многопоточном режиме, чего они не знали и удивлялись как медленно работает один поток на 16 ядрах. И кто теперь дурачок?
1) А бесплатный `npm audit` не подходит как анализатор зависимостей?
2) Вы как то встроили все эти инструменты в CI/CD?
Вот только ватсап шифрует на клиенте и хранит на клиенте, в отличие от тг.
База у каждого своя. Кто то спрашивает чем отличается var от let во всех подробностях, кто то про микро и макротаски, а по большому счету это все ***ня собачья а не база.
Большинство собесов в РФ как экзамен - тупая зубрежка, спрашивают много того, что забудется через пару недель, и готовиться к нему как к экзамену. Если нужно к собесу дополнительно готовиться, работая по 8 часов день по специальности, значит это плохой собес.
Так не мой, а мейнтейнера redux) Я в его issue скинул сразу свой PR с фиксом, он его проигнорил и протащил такую же правку через своего знакомого, через пол года.
Как то совсем не по человечески вышло.
Теперь нет.
Ну да, русская фамилия из бархатной книги..
Похожая история была с моим PR и react, вот только никто вслух не сказал из за чего не хотят мержить, и через пол года знакомый мейнтейнера redux, которому я скинул этот ПР, создал точно такой же, только хуже (без тестов) и его протащили мгновенно.
А зачем выкладывать туториал для старых модулей под Bridge, когда в последних версиях RN его уже нет?
А чем плоха просто папка с json файлами ответов, которые возвращаются в апи методах вместо fetch к серверу, с задержкой, и которую можно использовать в тестах, не поднимая никаких серверов?
Я привел пример где нельзя типизировать, в ответ это. Слив зачитан.
Комментарии здесь исключительно для вас, тех кто с пеной у рта доказывал бы что "строки это ужас, не проверяются в рантайме" и тп ерунду.
Типы все видны в среде разработки, учите матчасть потом спорьте. Больше настолько очевидные вещи объяснять не буду.
Потому что юнион строже типизирует и не создает дополнительные прослойки типов чем сильно упрощает код, без оверинжиниринга, который в большинстве случаев делает только хуже. И многим не понять пока не попользуются, к сожалению.
Судя по тому что я пишу на RN уже много лет и проблем не имею, видится что не смогла. Хотя скорей дело в лиде, который принял некомпетентное решение, которое уже принесло проблемы и еще аукнется в будущем.
Ну Flutter то конечно не позволяет писать говнокод))) С тем же успехом можно написать бесполезную статью как переписывали падающий говнокод с <любая технология> на <любая технология>.
Я привел множество примеров почему он хуже, и я бы никогда не выбрал его в 2024 году как инструмент разработки. Но если вы сделали такой выбор, удачи вам.
Тем кто способен только верить - религия. Компетентные выбирают умом.
Никто не спорит что их нет, но в TS намного больше возможностей типизации, а более строгая типизация - меньше ошибок в коде на этапе выполнения, быстрее разработка из за autocomplete и автоматическая "документация". Взять к примеру RRC, во флаттере абсолютно невозможно полностью типизировать код типа:
Они используются во всех опенсорс проектах от крутых технологических компаний типа Microsoft и др, как и в моем коде, и используются не зря. И код выше тому доказательство - они куда компактнее и читаемее чем те же enum. С такими заявлениями стало понятно что в TS вы совсем не разбираетесь.
Вот именно, и чем больше будет библиотек на флаттере, тем больше будет таких проблем, так как новички любят бездумно добавлять библиотеки чтобы "сложить два плюс два". Решение везде одинаковое - строго следить что добавляешь в проект, минимизировать нативные библиотеки.
Почитал ваше статью - серьезное преимущество это видимо потратить кучу денег компании на внедрение BDUI из за неудачного выбора технологии. Добавил там более подробный комментарий.
Dart хуже тк провоцирует писать в неудачном, устаревшем ООП стиле (это отдельный разговор), куда более многословный для одного и того же кода, особенно для функционального стиля, система типов TS это вообще шедевр по сравнению в Dart - Union type, generics и мн.др., наличие лучших фреймворков и библиотек, линтеров и тп.
Больше звучит как оправдание тимлида за неудачно выбранную технологию - про производительность скромно умолчали, но добавилась проблема отсутствия быстрых обновлений и следовательно костыль в виде BDUI.
А самая распространенная проблема в RN - бездумное добавление множества некачественных нативных зависимостей. Когда на флаттере появится столько же мусорных сторонних пакетов, "очумелые ручки" начнут их добавлять и там. Решение - минимум зависимостей, особенно нативных. А те что добавляются - тщательно анализируются, хотя бы по количеству issue и их поддержке. Работает кстати для любой технологии.
FPS главного потока в RN почти всегда максимальный (60).
Нет.
Если бы вы нормально переписали старый плохой код на хороший в том же RN, было бы еще лучше.
Фраза “особенно после добавления null safety” как бы намекает что вы не очень разбираетесь в правильном стэке для RN, а именно использовании TS.
Хотите меньше проблем с нативной частью, предпочитайте ненативные модули.
Еще один пустой комментарий без единого аргумента, так держать 👍
Очень конструктивный ответ, видимо нечего возразить 👍
Нет ни одной нормальной причины выбрать Flutter вместо React Native. Dart намного хуже TS, фреймворк хуже React, линтеры хуже, популярность сильно меньше чем React + TS, доступность (accessibility) хуже чем у React Native Web, система лейаутов у RN flex, как и в вебе. С новой архитектурой RN производительность больше не проблема, хотя и раньше не особо была проблемой. Проекты крутые на RN на слуху, в том числе от самих Facebook - и это крайне важно с точки зрения будущей поддержки, у Flutter все грустно, гугл его забросил и не использует. Мусор.
Важный момент не проговорен - если сэкономленные деньги не доплачивать за кредит, а внести на депозит / инвестировать / купить крипту, при равной доходности и проценте за вклад это равносильно доплате, но еще и дополнительная подушка безопасности.
Я как то отговорил товарищей переписывать nodejs на go, просто рассказав что nodejs нужно запускать в многопоточном режиме, чего они не знали и удивлялись как медленно работает один поток на 16 ядрах. И кто теперь дурачок?
Ненаучные размышления человека с низким iq о людях с высоким. Не рациональны, часто заблуждаются и тд и тп. Одним словом - бред.