Комментарии 73
Попробуйте написать комплексное кросс-платформенное приложение не на Flutter, а на чистом JS в одиночку за 1 месяц, и поймете что тренды не просто так появляются — на чистом JS у вас через месяц будет приложение готово только 5%, а на Flutter уже будет полноценное работоспособное красивое приложение, работающее на нескольких платформах
Яро интересуюсь флаттером (в основном его с++-движком), но для веба ещё не оптимизирован.
Как мне кажется "на мастере с FLUTTER_WEB_USE_SKIA=true" означает, что технология находится в самом начале графика из статьи, и сама статья показывает, почему стоит избегать таких технологий, пока они не вырастут во что-то серьезное.
и поймете что тренды не просто так появляются
Проблема не в том, что тренды появляются, а в том, что они часто меняются.
В результате, у меня сложилось впечатление, что новые веяния в JS, это не пригодное для маленьких компаний поделки требующие больших доработок. Продолжаю писать сайты на php+jquery.
Самое время
Есть и плюсы, конечно, у этих хуков, но реализовав несколько проектов с очень сложными компонентами (с композицией десятков и сотен хуков), первоначальное желание с ними работать пропало. Я не готов обсуждать детально в комментариях эти аргументы сейчас, так как сам не проводил тщательное параллельное сравнение, это просто навскидку.
Про мое умение компонировать сейчас не очень хочется говорить, если буду писать статью, то представлю полдесятка концептов композиции функций, но сделаю вывод, что по удобству разработки все они не дотягивают до классовых методов. Пока что тут нечего обсуждать.
Посмотрел видео, про контекст там не говорится, там про передачу стейта несколькими путями, кроме контекста и инджекта, а я использую как раз последние в продуктовой разработке.
Вообще я как раз про кастомные хуки говорил) Бывает длиннющая цепочка из полусотни, кроме шуток, и «плоско» — это только на верхнем уровне, то есть в функции рендера, в то время как если распутать весь клубок, получится множество взаимосвязей и изменений одних и тех же параметров.
useOnOpen(params);
useScrollToCurrentOption(params);
useClickOutside(params.selectRef, () => handleOutsideClick(params));
useSetValidation(params);
useDisabledChange(params);
Продолжаю лопатить статью за статьей, читаю рецепты, копаюсь в шаблонах сторонних проектов. Ваш коммент заставляет задуматься.
Не исключаю, что мои руки виноваты, но тем не менее. На классах все прекрасно работало…
До этого было много всего, начиная от различных не-ИТ-профессий, и заканчивая SEO/маркетингом в том же ИТ.
И знаете что бросается в глаза, при переходе в коллективы программистов? Что сложно себе представить более подверженных маркетингу людей, чем программистов. Не знаю с чем это связано, но вот складывается впечатление, что банальная, базовая защита от всяких там «купи-купи, вам это подойдет», которая есть у каждого современного человека, у программистов напрочь отсутствует.
Выходит какая-то новая технология. Маркетолог пишет продающий текст о том, какая она классная — и программисты воспринимают это за чистую правду. И не просто бегут пробовать и внедрять эту технологию, а начинают агитировать всех окружающих.
P.S.
С чем это связано — для меня загадка. Может быть, так решается внутреннее желание отрефакторить старый код. Ведь если просто сказать — «надо все переписать» — то нужно будет признать, что код был плохой (и сразу падает тень на тех, кто его писал). А если рефакторинг делается под предлогом «монолит это плохо, вот сейчас все перепишем на микросервисы и будет круто» — то звучит уже не так стыдно.
Представлю мою гипотезу про «с чем это связано».
На ранних этапах карьеры — это естественный отбор.
Программистами в результате остаются те, кто любит это дело, а не те кто радеют о бизнесе.
Бежать пробовать и внедрять технологии они бегут из любви к технологиям, а не потому что мозги промыли. Да, разумеется маркетологи влияют на то какую именно технологию бежит пробовать неофит, но ни в коей мере не пробуждает сам порыв.
Во вторых когда ты молодой и неопытный, у тебя еще нет любимого инструмента. Технологии в которых еще никто не разбирается выглядят более многообещающе на эту роль. И если ты внезапно стал главным спецом по %технология_икс% то чем больше эта технология применяется, тем больше твоя личная роль. Потому и агитируешь.
После получения лычки сеньора это уже в основном осознанный выбор.
Технологии меняются очень быстро, твой любимый инструмент тоже обречен на устаревание когда-либо. Поэтому постоянно надо пробовать что-то новое, хоть и в разумных пределах. Просто если бизнес этой необходимости не понимает, то хайповые технологии легче бизнесу продать. Маркетинг в этом случае действует не на программистов, а на бизнес.
То есть мне кажется что Вы заблуждаетесь, считая что программисты больше подвержены маркетингу. Не больше. Просто иногда следовать за рынком — выгодно для карьеры.
Хороший абзац с очень известной технической книги, про преждевременные решения
По теме статьи – если брать шире, речь вообще не про хайп, а про архитектуру решений.
Люди пользуются инструментами чтобы решать задачи быстро и качественно. Проблема в том, что в современных приложениях почти отсутствует проектирование архитектуры, потому что поставляются сильно связанные решения (тот же Angular и его экосистема). Эти Реакты, Vue, и прочее должны быть заменяемыми инструментами в решении, как и axios, чтобы в случае проблемы с инструментов его можно было просто заменить без переписывания системы.
Фактически сейчас приложения сильно зависят от самих инструментов, и именно поэтому как только инструмент становится легаси, так и всё приложение технически становится легаси, потому что без замены инструменты вывести его из этого состояния нельзя.
С другой стороны, архитектура в которую впишутся все фреймворки, библиотеки, это космическая фантастика, и так, очень вероятно, не получится.
Поэтому, имхо, нужно работать на трендовом инструменте, пытаясь по-возможности выкрутить опции в сторону абстракции.
Есть сейчас достаточно большое приложение на RN, переход на useEffect вместо componentDidUpdate позволяет все таки сделать код гораздо чище
Просто решили так
— Сначала, когда нужно внести правку в какой-то из компонентов UiKit переводим его на функциональный стиль
— Затем, понемногу, переписываем все экраны.
А переходить со связки Redux/Redux-Saga на какой-нибудь Recoil смысла нет вообще
Что скажете на счет effector?
this.isFetching = true;
const response = await apiRequest(`GET /items`);
this.items = response.items;
this.isFetching = false;
Что скажете?
Не совсем понял к чему это
fetchData = async () => {
// Компонент который использует эту переменную перерендеривается и показывается лоадер
this.isFetching = true;
// Получаем список чего-нибудь из АПИ
const response = await apiRequest(`GET /items`);
// Компонент который использует эту переменную теперь имеет данные для
рендера
this.items = response.items;
// Компонент который использует эту переменную перерендеривается и убирает лоадер и выводит список из переменной items
this.isFetching = false;
}
Как это касается моего вопроса?)
Если знаете подводные камни effector — буду рад услышать, что бы опробовать самому.
То, что вы сторонник mobx я уже понял)
Но пока что он меня так не впечатлил.
this.isFetching = true;
const response = await apiRequest(`GET /items`);
this.items = response.items;
this.isFetching = false;
Я не говорил проще, и я не говорил компактнее (хотя скорее всего так и есть).
Если вы хотите сказать, что в mobx компактнее — окей)
По существу — вы сталкивались с подводными камнями в effector? Поделитесь таковыми, пожалуйста.
Подводные камни — иммутабилен, неудобен в использовании, примитивен как палка, уровень раскрытия возможностей JS — 0%.
Если вы хотите поднасрать кому нибудь в проект, то да, притащить это будет хорошая идея.
Иммутабеленне уверен, что это минус.
Неудобен в использованиисубъективное суждение
Примитивен, как палкатак вы определитесь, он либо сложный, либо примитивен, как палка)
Уровень раскрытия возможностей JS — 0%.почему не -100% ?)
Ну и к слову, стоит ожидать от вас статьи «effector vs mobx vs ...»?
С удовольствием бы прочел!
В чем неудобство и кастрированость то собственно?)
Если для вас это не очевидно, то извиняйте, разговор ни о чем) Тем более вы говорите что знакомы с MobX и имеете такое мнение, для меня это нонсанс) Видать все таки не знакомы на самом деле.
Где я говорил, что знаком с mobx?
Я вообще говорил, что mobx плох?)
Стоит ожидать от вас статьи-сравнения?) А то пока что аргументов против толком не было — только вкусовщина.
Раз
codesandbox.io/s/interesting-snyder-v8k4o
И два
codesandbox.io/s/affectionate-keldysh-7mpwt
На effector'e и вообще на чем душе угодно и сравнить код с MobX'овским и сделаете выводы
codesandbox.io/s/effector-example-tudc7?file=/src/App.jsx
Касательно два потом как-то сделаю.
И отмечу, что effector я только изучаю — возможно есть ещё более элегантные решения, о которых я пока не знаю.
Вариант два я думаю вы так и не сделаете, потому что он не такой мега простой и банальный, и на effector'e вам уже гарантированно не понравится реализация)
А так в целом уже посмотрите на код, ведь очевидно насколько effector выглядит нелепо по сравнению с MobX и это на супер простом и банальном примере не имеющим отношения к реальной жизни, толи было бы хотя бы с примером номер два, который вы не сделали, вот там будет конкретный вырвиглаз) И не забываем, понятия локального стейта и глобального разные, это не одно и то же)
Исходя из вашего комментария, я понимаю, что effector вы даже не пробовали. Почитайте хотя бы о его концепциях.
И мне непонятно, зачем тогда effector везде хаять и превозносить mobx?
Код говорит сам за себя. Такое просто противопоказано применять не в одноразовых проектах где работает более одного человека.
const incr1Fx = createEvent("incr1");
const incr2Fx = createEvent("incr2");
const onTitleChanged1Fx = createEvent("onTitleChanged1Fx");
const onTitleChanged2Fx = createEvent("onTitleChanged2Fx");
const title1Fx = onTitleChanged1Fx.map(e => e.target.value);
const title2Fx = onTitleChanged2Fx.map(e => e.target.value);
const $counter1 = createStore(0).on(incr1Fx, state => state + 1);
const $counter2 = createStore(0).on(incr2Fx, state => state + 1);
const $title1 = createStore("First title").on(title1Fx, (state, e) => e);
const $title2 = createStore("Second title").on(title2Fx, (state, e) => e);
//...
const counter1 = useStore($counter1);
const counter2 = useStore($counter2);
const title1 = useStore($title1);
const title2 = useStore($title2);
Если по аналогии с вашим кодом, в примере с MobX тоже все сделать Inline, то будет так:
class LocalState {
@observable counter = 0;
@observable title = "title";
incr = () => { this.counter++; };
handleTitleChange = e => { this.title = e.target.value; };
}
class GlobalState {
@observable counter = 0;
@observable title = "global title";
incr = () => { this.counter++; };
handleTitleChange = e => { this.title = e.target.value; };
}
const globalState = new GlobalState();
///...
const [state] = useState(() => new LocalState());
И это только на супер простом и банальном примере не имеющим ничего общего с реальной бизнес логикой различный приложений, где тот или иной стейт изменяется по разному исходя из разных действий пользователя.
Даже в тупую сравнить кол-во символов:
MobX — 416 сами стейты и 49 инициализация внутри компонента, итого 465 символов
Effector — 600 сами стейты и 155 инициализация внутри компонента, итого 755 символов
40% разница и это в банальном примере, в чем-то похожем на реальную жизнь разница уже будет в разы.
И того, с чего я или ещё кто-то должен выбрать Effector вместо MobX'a? Если он хуже вообще по всем фронтам и параметрам. Да и не реакивный стейт менеджер в принципе никак не может быть лучше или сопоставим с реактивным, потому что это как сравнивать жигули 1980 года и Tesla Model X, и то и другое машина и то и другое может довести от точки А в точку Б, но то как они тебя повезут, и то какие технологии применены, тут уже целая пропасть между ними.
Вы своё субъективное мнение выставляете за данность уже, в который раз.
Вы не пробовали, вы даже не удосужились почитать хотя бы о базовых принципах effector, но уже заклеймили.
Так о каком опыте вы говорите? Беспочвенного хейтерства?
Из разряда:«Красные ягоды несладкие — вот я пробовал клюкву, и она была кислой. Так что клубника так же кислая — не ешьте.»
Количество символов? Вы серьёзно? Более веского аргумента нету? Ах да, вы ж не пробовали — у вас эфемерный опыт.
И так же вы сами решили, что он не реактивный — ну, у вас же опыт.
И как бы effector появился позже чем mobx, так что еще вопрос, кто тут tesla.
И tesla так же сперва не воспринимали всерьёз )…
Но вы и далее продолжайте хейтить то, с чем даже не ознакамливались.
На этом, я считаю, наш диалог окончен. Удачи)
Во всех инструментах есть плюсы и минусы. Вы же настолько превозносите один инструмент, что даже не разбираетесь с другими. Ну, удачи)
иммутабилен — это плюс, когда бэкенд весь иммутабилен,
и не надо туда-сюда голову перекючать ради 5% кода на js;
чем более примитивен инструмент, тем проще понять, как он внутри работает;
mobx работает как-бы _интуитивно_, но понять, как он _точно_ работает скорее всего будет сложней;
не все модные возможности JS хочется раскрывать, начиная от слетающего «this», и заканчивая прокси, когда написано одно короткое выражение, а отрабатывает хитрая магия.
Ну, если писать на mobx ежедневно, то возможно есть смысл со всем этим хорошенько разобраться и печатать на 25% символов меньше.
Или тут какие-то принципиальные бонусы?
Если что, я сам пока ни того, ни другого не выбрал.
Однако большинство программистов являются не производителями, а немными работниками, работающими на производителя. Поэтому объем продаж продукта и оптимизация затрат находятся, в лучшем случае, вне круга их материальных интересов. Интерес у них другой — поднять свою цену на рынке труда. А факт владения модной технологией при прочих равных условиях поднимает эту цену, и весьма заметно.
Так что для программистов, работающих по найму есть прямой материальный смысл следовать модным трендам, несмотря на все те аргументы, которые приводятся в статье.
Давайте рассмотрим практический пример. Я пользовался axios, это — отличная библиотека. Её код хорошо покрыт тестами, она отличается широкой поддержкой, у неё много GitHub-звёзд и так далее. Однажды мне попалась публикация, в которой дана рекомендация о том, что от axios нужно отказаться, создав собственное решение для загрузки различных материалов.
Мне кажется тут скорее проблема у самого автора.
Не надо следовать JavaScript-трендам