Мне код после другого разработчика проще прочитать на tailwind, чем фигню которую напишут в css
Фигню? Это какую? font-size? padiing? display? такую фигню? Вы вообще в курсе что такое css и какие в нем стили бывают? Или всё что вы видели это bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500 ?
Миксины зло, потому-что люди злоупотребляют ими
Что за бред, вы себя под всех подписываете? Если вы не в курсе что это, и как этим пользоваться, то это не говорит о том, что это зло.
Javascript - зло, потому-что люди злоупотребляют им.
Ну и в таком же духе для всего остального, надеюсь вы поняли абсурдность сие высказывания.
В scss проще сотворить дичь.
Какую конкретно?) Вы опять подписываете всех под себя?) Если вы пишете дичь в scss/css, то опять же, это сугубо ваши индивидуальные проблемы.
В Javascript проще сотворить дичь. В PHP проще сотворить дичь. В Angular проще сотворить дичь. Ну и так далее по списку.
в одном проекте это будет @mixin respond-to-desktop в другом @mixin adaptive-XL в другом @include respond($desktop)
И что? Как бы названия этих функций говорят сами за себя. Один раз вы их увидели и используйте нездоровье. Плюс никто не запрещает сделать для них алиасы, где:
@mixin respond-to-desktop === @mixin adaptive-XL
Tailwind ни так красив и ни компактен, да это зачастую лишняя div вложенность. Но это фреймворк, а значит накладывает свои законы и правила.
Да, всё что тут перечислили это жирные минусы.
а значит накладывает свои законы и правила.
И это тоже жирный минус.
Ну точнее может для совсем зеленого джуна который первый месяц в разработке это норм. Но для всех остальных, это жирный минус. Ибо связывать руки и ограничивать можно только тех, кто не ведает что творит, остальным это сильно мешает и вставляет палки в колеса.
Но если для вас это не очевидно, то вы пока всё ещё относитесь к категории которых лучше ограничивать во всем и не давать сделать шаг влево шаг вправо.
tailwind используется для коммерческой разработки, когда людей много
Вообще не вижу тут логику и здравый смысл. Какая разница сколько людей? Если работник #6 делает компонент DatePicker'a скажем, какая разница tailwind или css/scss/и т.п.? При чем тут коммерческая разработка? При чем тут кол-во людей?
Как думаешь сколько выхлопа css будет если они будут писать ручками или использовать классы к которым уже привязаны стили.
Компонентный подход, нет? А для всего остального оверхед в несколько килобайт в масштабах проекта это вообще ничто, причем ничто с большой буквы. Потому что в противовес
Ну тут как бы все очевидно. Более того, ты никак не зажат по стилям в отличии от tailwind.
Я не помню когда уже вообще использовал миксины или циклы, ну может когда потребовалось делать рандомные цвета, но это редкий случай
Не расстраивайтесь, если вы знаете как их применять и для чего. Ещё наберетесь опыта. Умные и опытные дядьки приведут вам примеры.
Вот один из них: Я надеюсь вы слышали о таком понятии как адаптивная верстка? Ну ка, что может быть более удобнее, очевиднее, читаемее, красивее чем вот это?
$media_size__desktop: 1301px;
$media_size__tablet: 1300px;
$media_size__mobile: 767px;
@mixin respond-to-desktop {
@media all and (min-width: $media_size__desktop) {
@content;
}
}
@mixin respond-to-tablet {
@media all and (min-width: $media_size__mobile + 1px) and (max-width: $media_size__tablet) {
@content;
}
}
@mixin respond-to-mobile {
@media all and (max-width: $media_size__mobile) {
@content;
}
}
@mixin respond-to-not-mobile {
// Догадайтесь сами
}
@mixin respond-to-not-desktop {
// Догадайтесь сами
}
@mixin respond-to-not-tablet {
// Догадайтесь сами
}
Sass переменные вообще использовать нельзя
Да вы что? Вот прям так, да? Какой кошмар, 9 лет использую, а оказывается нельзя. Ну если вы не знаете о проектировании и что и как лучше использовать, то это сугубо ваши проблемы)
их нельзя переопределить через js
Что?) Для каких утех ради?)) Наверное вы имеете ввиду переключение светлая тема/темная тема?)
Так то есть переменные нативного CSS если вы не в курсе. var(--base-text-color); И их можно переключать через js) А ещё секрет есть, не знаю, вы наверное не поверите
$base_text_color: var(--base-text-color);
Переменные SCSS могут содержать переменные CSS. Вот это поворот)
Сколько околоотказных сетов в неделю на каждую группу мышц?
Делаю каждый подход до отказа или околоотказа, получается 4 отказных подхода в 2 недели. Но у меня на факту многоповторки, подтягивания это 12-13 чистых со своим весом, приседания было и по 80 раз приседал, сейчас по 40 но с гирей 24кг (разницы в мышцах ног тоже не замечаю) Я давно перестал тягать веса где 6-8 повторов до отказа из-за травма опасности, плюс по 100500 раз по молодости травмировал и плечи и кисти и все что только можно. Но я тренировался по разному делал и по 12 отказных подходов на группу мышц в неделю, принципиальной разницы в моем случае нет, мне 34 года, генетика играет большую роль ещё. Вот помню мне было 18 лет, вот тогда все росло прекрасно и ел тогда только углеводы почти)) В итоге поставил себе во главу угла выносливость нежели мышечную массу и силу пиковую, для бытовых нужд выносливость куда важнее обычно)
Последние 4 месяца провожу эксперимент, сплит с отдыхом в 2 недели, т.е. ПН - подтягивания, отжимания ВТ - пресс, приседания СР - икры, спина ЧТ - боковые мышцы туловища ПТ-ВС - отдых далее ПН-ВС всё ещё отдых А дальше все по новой В дни отдыха хожу каждый день по 8км (вот только ввел это в практику, 3 месяца только), по времени ровно час занимает со средним пульсом ~130уд/мин
P.S. Я тренируюсь 19 лет, без фанатизма и химии. До начала эксперимента замерил обхват бицепса и каждый месяц сверяю, обхват не уменьшился ни на миллиметр. Последний год пью протеин ибо всю жизнь у меня явно было недостаточно животного белка в рационе, вешу 85кг, из протеина беру 90г белка в сутки вне зависимости тренируюсь в этот день или нет, примерно 150г животного белка в сутки выходит
Чем лучше технология, тем она проще, понятнее, и в ней меньше "магии" (KISS). И это основной показатель качества инженерии.
Инжектор vs Карбюратор ?)
АКПП с гидротрансформатором vs МКПП ?)
Голый Javascript vs React + JSX ?)
Ноги vs Велосипед ?)
Автомобиль vs Велосипед ?)
И этот список можно продолжать до бесконечности, где ваше "правило" не выполняется. Оно в каких-то конкретных случаях выполняется и я с ним полностью согласен, а в каких-то конкретных случаях оно не выполняется.
Даже подписаться на изменение чего нибудь не через React.Context ведет к багам
Что за фантазии? Вы вообще знаете в чём заключается суть React.Context?
Выкинуть React из приложения и заменить его на другую "библиотеку" зачастую равносильно полному переписыванию.
Его и нет смысла выкидывать если использовать по назначению - только как view слой. А управление состоянием как локальным так и глобальным доверить гораздо более удачным решениям, например MobX.
Карбюратор обладает куда более худшими ползовательскими характеристиками чем инжектор, а у нас речь про технологии, выполняющие абсолютно одно и то же.
А карбюратор и инжектор это не технологии для приготовления топливо воздушной смеси?)) Они не выполняют абсолютно одно и то же(топливо воздушная смесь)?)))
Пользователь не заметит разницы в использовании сайта что на redux, что на mobx, если они написаны с одними требованиями. Вопрос лишь в сложности реализации, поддержки и тп.
Это факт, так как как и не заметит разницы обернуты ли компоненты в HOC'и или нет. И да, действительно сложность реализации при использовании MobX куда ниже.
Если оборачивать каждую компоненту, vdom увеличиться в 2 раза. На огромных сайтах, запущенных на слабых [андроид] девайсах с севшей батарейкой может быть заметно.
Проверено многократно, не заметно, от слова совсем.
Я бы в такую историю не вписывался если есть выбор.
Есть такая штука - компромисс, да можно жертвовать нано и микросекундами в угоду значительному удобству и скорости написания кода.
на вашем mobx свет клином не сошелся. Хотя и там могут быть проблемы, проверять нет желания.
Логично, вы ничего не проверяете, просто берете утверждения из воздуха или где-то что-то прочитали/услышали и принимаете это за истину.
В современных языках типа Go и фреймворках типа React (да это фреймворк) от ООП отказались не просто так. И создатель Java признавал что зря добавил классы. Вот про это скоро напишу статью и Вас тоже приглашу.
А, то есть вот такого рода "логика" и "аргументы", ну тогда ясно понятно. [Facepalm]
фреймворках типа React (да это фреймворк)
React - библиотека для web и нативных(мобильные приложения) пользовательских интерфейсов.
Чем проще инструмент, тем меньше с ним проблем
Карбюратор - простой инструмент для ДВС. Казалось бы, с ним не должно быть проблем или совсем чуть чуть. Инжектор - сложный инструмент для ДВС и кучей датчиков, и электроники. Казалось бы, с ним должно быть полно проблем и надежность никакая. Реальность - инжектор уделывает карбюратор в щепки по всем параметрам. В том числе по кол-ву проблем.
Вот ваша логика либо черное либо белое и рассыпалась.
По поводу HOC - они 1) увеличивают vdom - по сути вместо одного слоя становится два (x2), что ухудшает производительность
Сколько это в цифрах? Десяток микросекунд? И это на полный цикл рендера всей страницы. А не перерендера компонента в отдельности.
усложняет типизацию - со всеми этими обертками часто сложно "прокинуть" нужный тип компоненты если он generic
Да ладно? observer в mobx-react-lite типизируется 1 в 1 так же как голый реакт компонент.
есть мнение, что все что сделано на классах по умолчанию плохо спроектировано
Серьезно?) Это чьё мнение интересно?) И какого перепуга оно должно вообще хоть что-то весить? Тем более зачем именно всё делать на классах? Там где удобно - классы, там где удобно - функции. Опять же классы классам рознь и функции функциям рознь.
отсутствие магии и оберток HOC (в функциональных компонентах). Любая проблема, которая когда либо возникала, имеет решение на redux - сюрпризов уже не будет.
У меня другой опыт - я насмотрелся на опытных разработчиков, реализовывающих "каждый чих" самостоятельно, и все это многократно переписывал.
Для начала с чего вы взяли что они реально опытные?) Например если человек Bob 15 лет работал на 2-3 проектах(а я таких знаю реально, прям лично), и человек Tom работал 5 лет на 10+ проектах, то Tom в 95% случаем будет на 3-4 головы лучшим разработчиком чем Bob который в опыте в годах аж на 10 лет больше работал. И это Tom построит гораздо более лучшую архитектуру на новом проекте, чем Bob, как минимум тупо за счет того что Tom видел в 3-4 раза больше проектов чем Bob.
Ну и конкретно в вашем сценарии вы видели плохих разработчиков, к великому сожалению их большинство( Так же как установщиков кондиционеров в лучшем случае 9 из 10 - плохие откровенно говоря, как тех кто ремонтирует автомобили, и т.д и т.п. Просто такова природа человека, в этом нет ничего удивительного и необычного, более того, таких людей никакие библиотеки не спасут, вот прям от слова совсем.
Откройте ваш проекты/любой проект допустим реактовский и посмотрите сколько в нем в зависимостях библиотек, а теперь внимание, по вашей логике код на этим проектах должен быть в худшем случае идеальный. а если там библиотек больше 20-30, так вообще великолепный, без вариантов, ведь люди столько идеальных готовых решений примели и у них просто нет шансов на ошибки и на плохой код.
А теперь окунемся в реальность. в лучшем случае код на этих проектах будет очень средненьким с натяжкой, а в среднем плохим, иногда ужасным. Какая мораль? Никакие библиотеки/фреймворки и т.п. ни от чего не спасают(разве что чуть чуть), если руки из нужного места растут, то все будет отлично, как без библиотек, так и с библиотеками, а если нет, то соответственно все будет плохо.
В 95% случаев (если не чаще) все это работает плохо, забаговано, и на больших проектах не подлежит исправлению кроме как "выкинуть и написать с нуля".
Возможно вы сами себе придумали критерии и по ним оценили что всё работает плохо. А если посмотреть объективно со стороны, то по факту все работает как минимум нормально. а то и хорошо.
Эти разработчики кстати чаще всего сами не видят никаких проблем в своем коде, и уж тем более не видят проблем в UX приложения.
Зависит от ваших индивидуальных критериев к коду. Мало ли, может вы пишете вложенные друг в друга теранарки, или не делаете early return в функциях(в том числе реакт компонентах), или вместо async/await пишете цепочки .then и т.д. и т.п. И считаете что это нормально и правильно, а другой код плохой. Хотя если быть честными самими с собой, то код, который ты читаешь первый раз сверху вниз и понимаешь что он делает, что будет дальше, какой будет результат его выполнения - это хороший код. А если ты смотришь и не понимаешь, без документации, без задавания вопросов автору кода и т.п. - этот код плохой. Но бывают и исключения из этих правил. в случаях когда очень сложная и навороченная бизнес логика, в таких случаях код будет плохим неизбежно и без вариантов. Где-то чуть менее плохим, где-то чуть более плохим, но суммарно плохим.
Да и то, комьюнити реакта понятие очень сильно растяжимое. и оно очень сильно разнится по уровню) Какой-то части нравится одно, другой другое, третьей третье и т.п.
Вы только посмотрите на управление состоянием. кто-то вообще голый реакт юзает, кто-то redux, кто-то mobx, кто-то zustand, кто-то effector, кто-то recoil и т.д. и т.п.
Или например работа со стилями, css modules, styled-components, typestyle, tailwind и т.д. и т.п.
У комьюнити реакта нет общей позиции ни по одному вопросу, кроме как да, мы все юзаем реакт как таковой.
Поэтому говорить и думать о том, что разработчики react не любят X, за сейчас X возьмем классы, бессмысленно, потому что кому-то они нравятся, а кому-то нет, вот и всё. а не так, что так заведено. И уж тем более принимать решения как самому писать код и что-то использовать основываясь на так называемое комьюнити точно не стоит, т.к. по факту вы при этом не основываетесь вообще ни на чем, всё будет зависит лишь от того каким конкретно людям вы зададите вопрос и как на него конкретно они ответят.
Так это же описание грубое, на пальцах, не подробное, никто не претендовал на подробный разбор, в контексте статьи это просто браузер и сайт. Понятное дело что в обобщенном виде это клиент и хост/сервер. Понятное дело что DNS может резолвить как операционка, так и браузер, так и вообще в целом любое приложение если захочет разработчик. И т.д. и т.п. Если подробно описать весь путь, в том числе через посредников в виде nginx, haproxy, apache и т.п. с разбором заголовков, это тема для отельной подробной статьи, а не общего интродакшена в общую суть дела.
Когда пользователь вводит URL-адрес в браузере, происходит следующее:
Браузер отправляет запрос на сервер через DNS для получения IP-адреса сайта.
После получения IP-адреса сервер отправляет браузеру HTTP-ответ с файлами сайта.
Браузер получает HTML, CSS и JavaScript файлы, и начинает процесс их обработки и отображения страницы.
У вас ошибка, вот так правильно:
Браузер отправляет запрос на сервер DNS для получения IP-адреса сайта.
После получения IP-адреса от DNS сервера, браузер отправляет серверу HTTP запрос. В случае с HTTPS перед самим запросом между сторонами происходит hand-shake с обменом ключей шифрования.
Браузер получает в ответе от сервера HTML
Браузер парсит HTML и может найти там ссылки на CSS, JS, картинки и т.п. И в зависимости от стратегии загрузки синхронно/асинхронно начинает их загружать
Ну это всё очень грубо говоря, прям совсем во все детали и нюансы вдаваться лень, ну основную суть ошибки я думаю вы поняли
Спасибо) Главное что код вы видите в первый раз, не знаете как написана по капотом asyncHelpers и ApIReq, но из их использования, сразу становится все понятно, как именно они работают/должны работать и что вообще происходит, какой будет результат, и какую гибкость все это дает)
Не знаю почему, но разработчики react почему то не любят все что связанно с классами, и считают это чуждым
Ну далеко не все конечно считают классы чем-то чуждым, всё напрямую зависит от их уровня и опыта, поэтому не стоит себя ущемлять в угоду тем, кто считает классы чем-то чужеродным
По этому я использую классический подход, который приемлем в react
Фишка react в том, что там нет такого понятия как "приемлемо в react" или "не приемлемо в react", react это всего лишь библиотека для рендеринга с жизненным циклом, не более. А как ей пользоваться решаем мы)
Из того что вы ответили получается что вы практически реализовали свой фреймворк на базе mobx, который используете от проекта к проекту, но только не оформили его в библиотеку.
Ну по сути да, за 12 лет из которых 8 лет чистого фронта и множество разных проектов, грех не обзавестись кучей решений и подходов на все случаи жизни
Что то в этом фреймворке требует изучения далеко не очевидной конфигурации mobx (как пример где fetching всегда false)
Не надо ничего изучать, тебе сказали 1 раз, реакции асинхронные по умолчанию, отсюда и автобатчинг, и всё, ты это услышал и понял, 5 секунд изучения)
что то не реализовано совсем - нормализация, пагинация, персистентность и мн. др., тот же optimistic response, и разумеется чтобы их добавить "просто код чутка измените под эти нужды и всё, элементарно же"
Ну вообще да, без шуток. Любой каприз, берешь и делаешь.
Вот только многое из этого не элементарно и потребует больших изменений, довольно багоемких, которые в идеале стоило бы еще и тестами покрыть.
Ну для вас может и больших, багоемких и т.п. А для меня они маленькие, быстрые и достаточно простые, как и для любого опытного разработчика. который привык решать задачи самостоятельно, а не заклеивать дыры библиотеками.
Оформите вашу идею в библиотеку, добавьте туда многое из того что обсудили и то что есть у "конкурентов", и возможно любители mobx ее оценят.
И лишать разработчиков самой важной вещи - думать своей головой, чтобы для них все более и более элементарные вещи становились "проблемой" и под каждый чих они искали библиотеку. Ну нет, не такое будущее разработки я хочу видеть. Эти вещи слишком тривиальные чтобы пользоваться ими в рамках библиотек.
Фигню? Это какую? font-size? padiing? display? такую фигню? Вы вообще в курсе что такое css и какие в нем стили бывают? Или всё что вы видели это
bg-gray-200 sm:bg-red-500 md:bg-blue-500 lg:bg-green-500?Что за бред, вы себя под всех подписываете? Если вы не в курсе что это, и как этим пользоваться, то это не говорит о том, что это зло.
Javascript - зло, потому-что люди злоупотребляют им.
Ну и в таком же духе для всего остального, надеюсь вы поняли абсурдность сие высказывания.
Какую конкретно?) Вы опять подписываете всех под себя?) Если вы пишете дичь в scss/css, то опять же, это сугубо ваши индивидуальные проблемы.
В Javascript проще сотворить дичь.
В PHP проще сотворить дичь.
В Angular проще сотворить дичь.
Ну и так далее по списку.
И что? Как бы названия этих функций говорят сами за себя. Один раз вы их увидели и используйте нездоровье. Плюс никто не запрещает сделать для них алиасы, где:
@mixin respond-to-desktop === @mixin adaptive-XLДа, всё что тут перечислили это жирные минусы.
И это тоже жирный минус.
Ну точнее может для совсем зеленого джуна который первый месяц в разработке это норм. Но для всех остальных, это жирный минус. Ибо связывать руки и ограничивать можно только тех, кто не ведает что творит, остальным это сильно мешает и вставляет палки в колеса.
Но если для вас это не очевидно, то вы пока всё ещё относитесь к категории которых лучше ограничивать во всем и не давать сделать шаг влево шаг вправо.
Вообще не вижу тут логику и здравый смысл. Какая разница сколько людей? Если работник #6 делает компонент DatePicker'a скажем, какая разница tailwind или css/scss/и т.п.? При чем тут коммерческая разработка? При чем тут кол-во людей?
Компонентный подход, нет? А для всего остального оверхед в несколько килобайт в масштабах проекта это вообще ничто, причем ничто с большой буквы. Потому что в противовес
против
Ну тут как бы все очевидно. Более того, ты никак не зажат по стилям в отличии от tailwind.
Не расстраивайтесь, если вы знаете как их применять и для чего. Ещё наберетесь опыта. Умные и опытные дядьки приведут вам примеры.
Вот один из них:
Я надеюсь вы слышали о таком понятии как адаптивная верстка?
Ну ка, что может быть более удобнее, очевиднее, читаемее, красивее чем вот это?
Где
Да вы что? Вот прям так, да? Какой кошмар, 9 лет использую, а оказывается нельзя. Ну если вы не знаете о проектировании и что и как лучше использовать, то это сугубо ваши проблемы)
Что?) Для каких утех ради?)) Наверное вы имеете ввиду переключение светлая тема/темная тема?)
Так то есть переменные нативного CSS если вы не в курсе.
var(--base-text-color);И их можно переключать через js) А ещё секрет есть, не знаю, вы наверное не поверитеПеременные SCSS могут содержать переменные CSS. Вот это поворот)
С козырей зашли)
Делаю каждый подход до отказа или околоотказа, получается 4 отказных подхода в 2 недели. Но у меня на факту многоповторки, подтягивания это 12-13 чистых со своим весом, приседания было и по 80 раз приседал, сейчас по 40 но с гирей 24кг (разницы в мышцах ног тоже не замечаю) Я давно перестал тягать веса где 6-8 повторов до отказа из-за травма опасности, плюс по 100500 раз по молодости травмировал и плечи и кисти и все что только можно.
Но я тренировался по разному делал и по 12 отказных подходов на группу мышц в неделю, принципиальной разницы в моем случае нет, мне 34 года, генетика играет большую роль ещё.
Вот помню мне было 18 лет, вот тогда все росло прекрасно и ел тогда только углеводы почти))
В итоге поставил себе во главу угла выносливость нежели мышечную массу и силу пиковую, для бытовых нужд выносливость куда важнее обычно)
Последние 4 месяца провожу эксперимент, сплит с отдыхом в 2 недели, т.е.
ПН - подтягивания, отжимания
ВТ - пресс, приседания
СР - икры, спина
ЧТ - боковые мышцы туловища
ПТ-ВС - отдых
далее ПН-ВС всё ещё отдых
А дальше все по новой
В дни отдыха хожу каждый день по 8км (вот только ввел это в практику, 3 месяца только), по времени ровно час занимает со средним пульсом ~130уд/мин
P.S.
Я тренируюсь 19 лет, без фанатизма и химии.
До начала эксперимента замерил обхват бицепса и каждый месяц сверяю, обхват не уменьшился ни на миллиметр.
Последний год пью протеин ибо всю жизнь у меня явно было недостаточно животного белка в рационе, вешу 85кг, из протеина беру 90г белка в сутки вне зависимости тренируюсь в этот день или нет, примерно 150г животного белка в сутки выходит
Спасибо за статью! Сам последние 19 лет жизни занимаюсь силовыми, но без фанатизма
У вас опечатка, вместо ничем, вы написали ничего
Спасибо за статью! До 7 версии ещё давно все знал, когда писал на PHP, а вот всё что после уже не следил, спасибо что собрали вcе воедино.
@gen1leeЯ так понимаю вы передумали или не смогли аналог сделать на основе обычного useRef без лишних библиотек?
Инжектор vs Карбюратор ?)
АКПП с гидротрансформатором vs МКПП ?)
Голый Javascript vs React + JSX ?)
Ноги vs Велосипед ?)
Автомобиль vs Велосипед ?)
И этот список можно продолжать до бесконечности, где ваше "правило" не выполняется. Оно в каких-то конкретных случаях выполняется и я с ним полностью согласен, а в каких-то конкретных случаях оно не выполняется.
Как локально состояние, так и глобальное. А вот и пример
https://stackblitz.com/edit/vitejs-vite-ffchmx?file=src%2Fpages%2Fmain%2Findex.tsx&terminal=dev
Сделайте тоже самое, что пунктом выше и пришлите ссылку
Что за фантазии? Вы вообще знаете в чём заключается суть React.Context?
Его и нет смысла выкидывать если использовать по назначению - только как view слой. А управление состоянием как локальным так и глобальным доверить гораздо более удачным решениям, например MobX.
А карбюратор и инжектор это не технологии для приготовления топливо воздушной смеси?))
Они не выполняют абсолютно одно и то же(топливо воздушная смесь)?)))
Это факт, так как как и не заметит разницы обернуты ли компоненты в HOC'и или нет. И да, действительно сложность реализации при использовании MobX куда ниже.
Проверено многократно, не заметно, от слова совсем.
Есть такая штука - компромисс, да можно жертвовать нано и микросекундами в угоду значительному удобству и скорости написания кода.
Логично, вы ничего не проверяете, просто берете утверждения из воздуха или где-то что-то прочитали/услышали и принимаете это за истину.
А, то есть вот такого рода "логика" и "аргументы", ну тогда ясно понятно. [Facepalm]
React - библиотека для web и нативных(мобильные приложения) пользовательских интерфейсов.
Карбюратор - простой инструмент для ДВС. Казалось бы, с ним не должно быть проблем или совсем чуть чуть.
Инжектор - сложный инструмент для ДВС и кучей датчиков, и электроники. Казалось бы, с ним должно быть полно проблем и надежность никакая.
Реальность - инжектор уделывает карбюратор в щепки по всем параметрам. В том числе по кол-ву проблем.
Вот ваша логика либо черное либо белое и рассыпалась.
Сколько это в цифрах? Десяток микросекунд? И это на полный цикл рендера всей страницы. А не перерендера компонента в отдельности.
Да ладно? observer в mobx-react-lite типизируется 1 в 1 так же как голый реакт компонент.
Серьезно?) Это чьё мнение интересно?) И какого перепуга оно должно вообще хоть что-то весить? Тем более зачем именно всё делать на классах? Там где удобно - классы, там где удобно - функции. Опять же классы классам рознь и функции функциям рознь.
О каких конкретно сюрпризах идёт речь?
Для начала с чего вы взяли что они реально опытные?) Например если человек Bob 15 лет работал на 2-3 проектах(а я таких знаю реально, прям лично), и человек Tom работал 5 лет на 10+ проектах, то Tom в 95% случаем будет на 3-4 головы лучшим разработчиком чем Bob который в опыте в годах аж на 10 лет больше работал. И это Tom построит гораздо более лучшую архитектуру на новом проекте, чем Bob, как минимум тупо за счет того что Tom видел в 3-4 раза больше проектов чем Bob.
Ну и конкретно в вашем сценарии вы видели плохих разработчиков, к великому сожалению их большинство( Так же как установщиков кондиционеров в лучшем случае 9 из 10 - плохие откровенно говоря, как тех кто ремонтирует автомобили, и т.д и т.п. Просто такова природа человека, в этом нет ничего удивительного и необычного, более того, таких людей никакие библиотеки не спасут, вот прям от слова совсем.
Откройте ваш проекты/любой проект допустим реактовский и посмотрите сколько в нем в зависимостях библиотек, а теперь внимание, по вашей логике код на этим проектах должен быть в худшем случае идеальный. а если там библиотек больше 20-30, так вообще великолепный, без вариантов, ведь люди столько идеальных готовых решений примели и у них просто нет шансов на ошибки и на плохой код.
А теперь окунемся в реальность. в лучшем случае код на этих проектах будет очень средненьким с натяжкой, а в среднем плохим, иногда ужасным.
Какая мораль? Никакие библиотеки/фреймворки и т.п. ни от чего не спасают(разве что чуть чуть), если руки из нужного места растут, то все будет отлично, как без библиотек, так и с библиотеками, а если нет, то соответственно все будет плохо.
Возможно вы сами себе придумали критерии и по ним оценили что всё работает плохо. А если посмотреть объективно со стороны, то по факту все работает как минимум нормально. а то и хорошо.
Зависит от ваших индивидуальных критериев к коду. Мало ли, может вы пишете вложенные друг в друга теранарки, или не делаете early return в функциях(в том числе реакт компонентах), или вместо async/await пишете цепочки .then и т.д. и т.п. И считаете что это нормально и правильно, а другой код плохой.
Хотя если быть честными самими с собой, то код, который ты читаешь первый раз сверху вниз и понимаешь что он делает, что будет дальше, какой будет результат его выполнения - это хороший код.
А если ты смотришь и не понимаешь, без документации, без задавания вопросов автору кода и т.п. - этот код плохой.
Но бывают и исключения из этих правил. в случаях когда очень сложная и навороченная бизнес логика, в таких случаях код будет плохим неизбежно и без вариантов. Где-то чуть менее плохим, где-то чуть более плохим, но суммарно плохим.
Да и то, комьюнити реакта понятие очень сильно растяжимое. и оно очень сильно разнится по уровню) Какой-то части нравится одно, другой другое, третьей третье и т.п.
Вы только посмотрите на управление состоянием. кто-то вообще голый реакт юзает, кто-то redux, кто-то mobx, кто-то zustand, кто-то effector, кто-то recoil и т.д. и т.п.
Или например работа со стилями, css modules, styled-components, typestyle, tailwind и т.д. и т.п.
У комьюнити реакта нет общей позиции ни по одному вопросу, кроме как да, мы все юзаем реакт как таковой.
Поэтому говорить и думать о том, что разработчики react не любят X, за сейчас X возьмем классы, бессмысленно, потому что кому-то они нравятся, а кому-то нет, вот и всё. а не так, что так заведено. И уж тем более принимать решения как самому писать код и что-то использовать основываясь на так называемое комьюнити точно не стоит, т.к. по факту вы при этом не основываетесь вообще ни на чем, всё будет зависит лишь от того каким конкретно людям вы зададите вопрос и как на него конкретно они ответят.
Так это же описание грубое, на пальцах, не подробное, никто не претендовал на подробный разбор, в контексте статьи это просто браузер и сайт. Понятное дело что в обобщенном виде это клиент и хост/сервер. Понятное дело что DNS может резолвить как операционка, так и браузер, так и вообще в целом любое приложение если захочет разработчик. И т.д. и т.п. Если подробно описать весь путь, в том числе через посредников в виде nginx, haproxy, apache и т.п. с разбором заголовков, это тема для отельной подробной статьи, а не общего интродакшена в общую суть дела.
У вас ошибка, вот так правильно:
Браузер отправляет запрос на сервер DNS для получения IP-адреса сайта.
После получения IP-адреса от DNS сервера, браузер отправляет серверу HTTP запрос. В случае с HTTPS перед самим запросом между сторонами происходит hand-shake с обменом ключей шифрования.
Браузер получает в ответе от сервера HTML
Браузер парсит HTML и может найти там ссылки на CSS, JS, картинки и т.п. И в зависимости от стратегии загрузки синхронно/асинхронно начинает их загружать
Ну это всё очень грубо говоря, прям совсем во все детали и нюансы вдаваться лень, ну основную суть ошибки я думаю вы поняли
Спасибо) Главное что код вы видите в первый раз, не знаете как написана по капотом asyncHelpers и ApIReq, но из их использования, сразу становится все понятно, как именно они работают/должны работать и что вообще происходит, какой будет результат, и какую гибкость все это дает)
Ну далеко не все конечно считают классы чем-то чуждым, всё напрямую зависит от их уровня и опыта, поэтому не стоит себя ущемлять в угоду тем, кто считает классы чем-то чужеродным
Фишка react в том, что там нет такого понятия как "приемлемо в react" или "не приемлемо в react", react это всего лишь библиотека для рендеринга с жизненным циклом, не более. А как ей пользоваться решаем мы)
Ну по сути да, за 12 лет из которых 8 лет чистого фронта и множество разных проектов, грех не обзавестись кучей решений и подходов на все случаи жизни
Не надо ничего изучать, тебе сказали 1 раз, реакции асинхронные по умолчанию, отсюда и автобатчинг, и всё, ты это услышал и понял, 5 секунд изучения)
Ну вообще да, без шуток. Любой каприз, берешь и делаешь.
Ну для вас может и больших, багоемких и т.п. А для меня они маленькие, быстрые и достаточно простые, как и для любого опытного разработчика. который привык решать задачи самостоятельно, а не заклеивать дыры библиотеками.
И лишать разработчиков самой важной вещи - думать своей головой, чтобы для них все более и более элементарные вещи становились "проблемой" и под каждый чих они искали библиотеку. Ну нет, не такое будущее разработки я хочу видеть. Эти вещи слишком тривиальные чтобы пользоваться ими в рамках библиотек.