Тема хантинга в вузах не раскрыта и имеет как плюсы так и минусы. Мнение о чём-то нельзя упростить до "хорошо" и "плохо", нужно разбирать каждый аспект и делать оценку каждого аспекта.
Спойлер
В итоге окажется что хантинг в вузах это не хорошо и не плохо =)
Сравнение двух подходов, когда у нас в качестве рендера передается функция и когда в качестве рендера передается компонент. Возможно вы компонент перепутали с элементом?
Т.е. по факту это скрывает реализацию. Отсюда вытекают плюсы и минусы.
Нуу и не хватает разбора с подходом в виде проброса компонента вместо функции. Т.е. сравнение проброса компонента, который принимает такие же пропсы, как и аргументы пробрасываемой функции.
Ваш комментарий только подтверждает вашу зашоренность.
Я нигде в ветке не защищал и не продвигал реакт. Но ваша зашоренность не позволят вам объективно участвовать в дискуссии и воспринимать тезисы других людей.
У вас явно проблемы с коммуникацией, поэтому не понимаете почему везде есть компромиссы, в т.ч. в разработке. Да, в программировании компромиссов почти нет, но мы говорим про разработку, а не про научный подход.
Мне вас в некотором смысле жаль, т.к. явно знания есть, но вы не можете их реализовать из-за зашоренности.
Как много примеров компаний вы знаете которые закрылись из-за плохого фронта?
Если следовать вашей статье, то нужно ставить условия бизнесу, а не искать компромиссы.
Но если вы так будете делать, то бизнес найдет более подходящего разработчика, который за неделю склепает фиг пойми что, фиг пойми как, главное что будет работать и денег меньше потратит. И продукт запустят через неделю, а не через месяц.
Если бы бизнес думал о том, как сделать лучше в долгосрочной перспективе, то в каждой стране были бы заводы и везде был бы замкнутый цикл производства. Но почему-то бизнес импортирует товар за три копейки и продает в сто раз дороже, нежели производит за 30 копеек и продаёт в 10 раз дороже.
Там, где есть риски, есть и потребность выбирать менее популярные, но более подходящие и менее рискованные (в данном случае под менее рискованным подразумевается больший контроль над технологией и независимость) подходы. Но это тот случай, когда мы говорим про возможные потери бизнеса.
Чем больше разработчиков знающих определенную технологию, тем меньше рисков у бизнеса.
И поэтому написать костыль для известной штуки дешевле и меньше рисков, чем брать малопопулярную технологию.
Вы почему-то используете тезис, что "Давайте сделаем уникальное решение, которое на 100% будет подходить для нас", но при этом забываете, что такое решение придется как поддерживать, так и обучать новые кадры для работы с данным решением. Хотя использовать известную технологию и подогнать её под себя тоже не является бескомпромиссным решением, но всё же в обоих случаях есть компромиссы.
Т.е. если мы говорим про известную технологию, то меньше рисков, что столкнемся со специфичными багами, что в будущем нужно будет долго разбираться в легаси, что новые сотрудники будут долго вкатываться в процесс. Но получаем проблему с зависимостью от мейнтейнеров.
Это же прям в вашей статье написано, что вы выбрали непопулярное решение (Dart) для веба и столкнулись с проблемами в процессе разработки, что в итоге стоило денег компании.
Возможно проблема в том, что вы понимаете под популярностью и известностью - хайп, а не зрелость и распространенность. Поэтому вы неверно толкуете высказывания других пользователей.
В параллельной вселеной много чего сделано по другому. Но это не означает, что всё что хорошо "там", будет так же хорошо и для "здесь".
Вы можете сколь угодно много заниматься научной работой, но только часть из наработок попадёт на рынок и будет жизнеспособными. На исследования выделяется отдельный фонд. Если бизнес будет все деньги тратить только на исследования, то он не будет зарабатывать. Поэтому в бизнесе много типовых задач, для решения которых ты будешь использовать одни и те же инструменты, т.к. такое сочетание позволит удешевить и ускорить разработку, а так же принесет прибыль.
Кто в комментах критикует архитектуру? Её невозможно критиковать, потому что автор не предоставил информации о ней. Максимум что есть, это конкретное решение про мемоизацию. Собственно это решение и критикуется, а точнее подход автора к решению проблемы.
При этом заявления автора, что он только через 6 лет понял на практике эффективность мемоизации, вызывает минимум улыбку.
И что ему предложить? Люди в комментах попытались догадаться что и как у автора сделано, попытались предложить решения на основе своих догадок.
Или вы предлагаете собрать список статей по реакту и скинуть ему ссылки в коммент? Если такие проблемы с мемоизацией, то явно есть проблемы в принципе с теорией. Ну так займитесь тогда этим.
По статье можно сделать вывод о том, что у автора проблема с использованием технологий, а от сюда уже вывод о том, что скорее всего и проблема с проектировкой, т.к. шанс удачной проектировки системы без теории 50% (либо нормально либо нет).
Я занимаюсь фронтенд разработкой на React последние 6 лет (в роли full-stack разработчика). Я знал и слышал, что существуют хуки useCallback и useMemo, которые нужны для оптимизации рендеринга. При этом про их использование я слышал только в теории или на собеседованиях.
Это шутка? Статья была заготовлена для 1 апреля? Или под "последние" вы имеете ввиду что больше не будете разрабатывать на реакте?
Мемоизация уже заметно помогает при рендере больших списков, где нужно прокинуть хотя бы один параметр вниз, в каждый дочерний компонент. Т.е. вы за 6 лет не делали интерактивных приложений, а только условные лендинги?
Но если рассматривать вашу проблему, а не отдельно мемоизацию, то вам сторы не помогут. У вас в принципе проблема с проектировкой системы и использованием технологий. Можете просто почитать статьи аля "React best practice", "React in action".
Если свести мой посыл до пары предложений, то он будет звучать примерно так:
Если у вас нет никаких вводных данных и ограничений, то делайте так, как хотите, так, как больше опыта, т.к. для большинства задач подойдёт множество разных решений, в том числе монолит/микросервис. Придерживайтесь правилам написания кода, они позволят в будущем с меньшей болью переходить что в одну сторону, что в другую. Но в большинстве случаев это не потребуется.
Размышлять глобально над архитектурой стоит только тогда, когда есть какие-то вводные.
Пусть развлекаются как хотят) Особенно если вносят вклад в сообщество.
У меня был период в жизни, когда я пытался добиться идеала от архитектуры. И это был самый непродуктивный период. Оттуда я вынес то, что идеала не существует и нужно идти на компромиссы =)
Если вы думаете, что для успеха достаточно представить/выпустить идею/технологию, то это не так. Поддержка не менее важна. Как самого формата, так и экосистемы.
Библиотека на 600 строчек не требует "большой поддержки". Даже если вас что-то не устроит - вы её легко перепишете за пол дня с нуля.
Я боюсь что подобные темы развернуто больше подходят не для статей, а для более глубоких и больших работ.
Я высказал общее мнение по поводу "Статья на тему архитектуры приложение". Т.е. высказал не конкретно о вашей статье, а о всех статьях на эту тему, включая вашу =)
Ну и я хотел подчеркнуть для "неопределившихся", что не нужно засиживаться над продумыванием. Если у вас продумывание архитектуры превращается в бесконечный квест, то лучше сделать как умеете, просто держите код в хорошем состоянии. Что-то сделав, задеплоив, когда начнут пользоваться люди, тогда вы поймёте в какую сторону стоит развивать систему.
У меня складывается стойкое ощущение, что вы работаете только в своей экосистеме и не работаете в реальном мире. Вообщем какая-то оторванность от реальности.
Аналогия верная, вы сами назначили себя экспертом, сами решили что имеете право выносить решение "проф непригодность" будто судья.
Мне в таких статьях не нравится то, что они дают только поверхностное представление о подходах.
Проблема не в авторах и не в статьях. Проблема в том, что такие темы можно понять только на практике. Если изучать по теории, то придется изучать множество чужих практик. И это всё займет не мало времени, и не даст того, что дадут свои набитые шишки.
Т.е. для незнающих это даст только поверхностные знания, для знающих вспомнят теорию.
Это на словах может быть легко развернуть кластер с микросервисами, либо наоборот, использовать эффективно все 64 ядра. Но по факту, знающему человеку нет особой разницы, 16 машин по 4 ядра, или одна на 64. Есть задача, есть ресурсы, есть существующая инфра. И уже от вводных начинаешь скакать и придумывать решение на компромиссах. Я не говорю что можно выполнить любую задачу из любых вводных, Я говорю о том, что большинство задач можно решить разными способами и построить разные архитектуры.
Точно так же и в выборе монолит/микросервис. Если соблюдать простой принцип разделения ответственности, то в 90%+ случаев этого будет достаточно для выделения отдельных БЛ в сервисы.
Откуда такие выводы? =)
Тема хантинга в вузах не раскрыта и имеет как плюсы так и минусы. Мнение о чём-то нельзя упростить до "хорошо" и "плохо", нужно разбирать каждый аспект и делать оценку каждого аспекта.
Спойлер
В итоге окажется что хантинг в вузах это не хорошо и не плохо =)
Почему же? =)
Сравнение двух подходов, когда у нас в качестве рендера передается функция и когда в качестве рендера передается компонент.
Возможно вы компонент перепутали с элементом?
Всё таки это чаще используется для рендера массива данных, но когда нужна так же некоторая логика (к примеру фильтрация) из дочернего компонента.
К примеру: https://reactnative.dev/docs/flatlist#required-renderitem
Если рендер проп используется для рендера компонента с данными из дочернего, то я чаще встречал когда метод передается в качестве children, а не кастомного пропса.
К примеру: https://www.react-spring.dev/docs/components и https://v5.reactrouter.com/web/api/match/null-matches
Т.е. по факту это скрывает реализацию. Отсюда вытекают плюсы и минусы.
Нуу и не хватает разбора с подходом в виде проброса компонента вместо функции. Т.е. сравнение проброса компонента, который принимает такие же пропсы, как и аргументы пробрасываемой функции.
Ваш комментарий только подтверждает вашу зашоренность.
Я нигде в ветке не защищал и не продвигал реакт. Но ваша зашоренность не позволят вам объективно участвовать в дискуссии и воспринимать тезисы других людей.
Откуда такие выводы?
Человек спросил о работе компаний с вузами для привлечения кадров, Я написал, что такая работа проводится в т.ч. через ппс.
У вас явно проблемы с коммуникацией, поэтому не понимаете почему везде есть компромиссы, в т.ч. в разработке. Да, в программировании компромиссов почти нет, но мы говорим про разработку, а не про научный подход.
Мне вас в некотором смысле жаль, т.к. явно знания есть, но вы не можете их реализовать из-за зашоренности.
Как много примеров компаний вы знаете которые закрылись из-за плохого фронта?
Если следовать вашей статье, то нужно ставить условия бизнесу, а не искать компромиссы.
Но если вы так будете делать, то бизнес найдет более подходящего разработчика, который за неделю склепает фиг пойми что, фиг пойми как, главное что будет работать и денег меньше потратит. И продукт запустят через неделю, а не через месяц.
Если бы бизнес думал о том, как сделать лучше в долгосрочной перспективе, то в каждой стране были бы заводы и везде был бы замкнутый цикл производства. Но почему-то бизнес импортирует товар за три копейки и продает в сто раз дороже, нежели производит за 30 копеек и продаёт в 10 раз дороже.
Там, где есть риски, есть и потребность выбирать менее популярные, но более подходящие и менее рискованные (в данном случае под менее рискованным подразумевается больший контроль над технологией и независимость) подходы. Но это тот случай, когда мы говорим про возможные потери бизнеса.
Чем больше разработчиков знающих определенную технологию, тем меньше рисков у бизнеса.
И поэтому написать костыль для известной штуки дешевле и меньше рисков, чем брать малопопулярную технологию.
Вы почему-то используете тезис, что "Давайте сделаем уникальное решение, которое на 100% будет подходить для нас", но при этом забываете, что такое решение придется как поддерживать, так и обучать новые кадры для работы с данным решением. Хотя использовать известную технологию и подогнать её под себя тоже не является бескомпромиссным решением, но всё же в обоих случаях есть компромиссы.
Т.е. если мы говорим про известную технологию, то меньше рисков, что столкнемся со специфичными багами, что в будущем нужно будет долго разбираться в легаси, что новые сотрудники будут долго вкатываться в процесс. Но получаем проблему с зависимостью от мейнтейнеров.
Это же прям в вашей статье написано, что вы выбрали непопулярное решение (Dart) для веба и столкнулись с проблемами в процессе разработки, что в итоге стоило денег компании.
Возможно проблема в том, что вы понимаете под популярностью и известностью - хайп, а не зрелость и распространенность. Поэтому вы неверно толкуете высказывания других пользователей.
В параллельной вселеной много чего сделано по другому.
Но это не означает, что всё что хорошо "там", будет так же хорошо и для "здесь".
Вы можете сколь угодно много заниматься научной работой, но только часть из наработок попадёт на рынок и будет жизнеспособными.
На исследования выделяется отдельный фонд. Если бизнес будет все деньги тратить только на исследования, то он не будет зарабатывать. Поэтому в бизнесе много типовых задач, для решения которых ты будешь использовать одни и те же инструменты, т.к. такое сочетание позволит удешевить и ускорить разработку, а так же принесет прибыль.
Мне кажется во всех универах преподы имеют контакты с компаниями и поставляют им кандидатов...
По крайней мере в двух разных универах в разных городах я знаю это точно.
Тут нет спора про архитектуру. Чтобы про неё спорить нужно чтобы были какие-то тезисы про архитектуру. А пока что тут только догадки про архитектуру.
Кто в комментах критикует архитектуру?
Её невозможно критиковать, потому что автор не предоставил информации о ней.
Максимум что есть, это конкретное решение про мемоизацию.
Собственно это решение и критикуется, а точнее подход автора к решению проблемы.
При этом заявления автора, что он только через 6 лет понял на практике эффективность мемоизации, вызывает минимум улыбку.
И что ему предложить? Люди в комментах попытались догадаться что и как у автора сделано, попытались предложить решения на основе своих догадок.
Или вы предлагаете собрать список статей по реакту и скинуть ему ссылки в коммент?
Если такие проблемы с мемоизацией, то явно есть проблемы в принципе с теорией.
Ну так займитесь тогда этим.
По статье можно сделать вывод о том, что у автора проблема с использованием технологий, а от сюда уже вывод о том, что скорее всего и проблема с проектировкой, т.к. шанс удачной проектировки системы без теории 50% (либо нормально либо нет).
У вас в статье даже нет информации о профилировании...
"На глаз" это не решение, "на глаз" это костыль.
У вас проблемы с теорией, пробежаться глазами, а тем более бежать от проблемы (ставя минусы комментам и не замечать) не даст вам никакого профита.
Это шутка? Статья была заготовлена для 1 апреля? Или под "последние" вы имеете ввиду что больше не будете разрабатывать на реакте?
Мемоизация уже заметно помогает при рендере больших списков, где нужно прокинуть хотя бы один параметр вниз, в каждый дочерний компонент. Т.е. вы за 6 лет не делали интерактивных приложений, а только условные лендинги?
Я вам могу даже один пример зачем нужна мемоизация показать, но там видно, что новичок писал статью, а не человек с 6 годами опыта. https://habr.com/ru/articles/873044/comments/#comment_27773258
Но если рассматривать вашу проблему, а не отдельно мемоизацию, то вам сторы не помогут. У вас в принципе проблема с проектировкой системы и использованием технологий. Можете просто почитать статьи аля "React best practice", "React in action".
Оно над (или под, в зависимости от десктоп/моб). Т.е. нужно с новой строки, а не выделять текст.
В целом верно, но ещё дополнение =)
Если свести мой посыл до пары предложений, то он будет звучать примерно так:
Если у вас нет никаких вводных данных и ограничений, то делайте так, как хотите, так, как больше опыта, т.к. для большинства задач подойдёт множество разных решений, в том числе монолит/микросервис. Придерживайтесь правилам написания кода, они позволят в будущем с меньшей болью переходить что в одну сторону, что в другую. Но в большинстве случаев это не потребуется.
Размышлять глобально над архитектурой стоит только тогда, когда есть какие-то вводные.
Пусть развлекаются как хотят) Особенно если вносят вклад в сообщество.
У меня был период в жизни, когда я пытался добиться идеала от архитектуры. И это был самый непродуктивный период. Оттуда я вынес то, что идеала не существует и нужно идти на компромиссы =)
Формат это же не только описать спецификацию =)
Если вы думаете, что для успеха достаточно представить/выпустить идею/технологию, то это не так. Поддержка не менее важна. Как самого формата, так и экосистемы.
Данные высказывания довольно инфантильны =)
Я от вас не жду этого =)
Я боюсь что подобные темы развернуто больше подходят не для статей, а для более глубоких и больших работ.
Я высказал общее мнение по поводу "Статья на тему архитектуры приложение". Т.е. высказал не конкретно о вашей статье, а о всех статьях на эту тему, включая вашу =)
Ну и я хотел подчеркнуть для "неопределившихся", что не нужно засиживаться над продумыванием. Если у вас продумывание архитектуры превращается в бесконечный квест, то лучше сделать как умеете, просто держите код в хорошем состоянии. Что-то сделав, задеплоив, когда начнут пользоваться люди, тогда вы поймёте в какую сторону стоит развивать систему.
Мы вроде про формат говорим, а не про библиотеку.
У меня складывается стойкое ощущение, что вы работаете только в своей экосистеме и не работаете в реальном мире. Вообщем какая-то оторванность от реальности.
Аналогия верная, вы сами назначили себя экспертом, сами решили что имеете право выносить решение "проф непригодность" будто судья.
Мне в таких статьях не нравится то, что они дают только поверхностное представление о подходах.
Проблема не в авторах и не в статьях. Проблема в том, что такие темы можно понять только на практике. Если изучать по теории, то придется изучать множество чужих практик. И это всё займет не мало времени, и не даст того, что дадут свои набитые шишки.
Т.е. для незнающих это даст только поверхностные знания, для знающих вспомнят теорию.
Это на словах может быть легко развернуть кластер с микросервисами, либо наоборот, использовать эффективно все 64 ядра. Но по факту, знающему человеку нет особой разницы, 16 машин по 4 ядра, или одна на 64. Есть задача, есть ресурсы, есть существующая инфра. И уже от вводных начинаешь скакать и придумывать решение на компромиссах. Я не говорю что можно выполнить любую задачу из любых вводных, Я говорю о том, что большинство задач можно решить разными способами и построить разные архитектуры.
Точно так же и в выборе монолит/микросервис. Если соблюдать простой принцип разделения ответственности, то в 90%+ случаев этого будет достаточно для выделения отдельных БЛ в сервисы.