company_banner

Не надо следовать JavaScript-трендам

Автор оригинала: Nikola Đuza
  • Перевод
Однажды, когда у вас выдался не самый светлый день, вы увидели новый твит о том, как пользоваться хуками React. Но по какой-то причине ваша компания или ваша команда ещё не перешли на хуки. Или, может быть, вы ими пользуетесь, но не таким способом, который можно было бы назвать «трендовым». Возможно, вы применяете Vue.js или Angular, но React-хуки лезут буквально отовсюду, вы видите сообщения о них так часто, что возникает такое ощущение, будто скоро о них «заговорит» даже микроволновка.

Так как день у вас был не очень удачным, вы начали задаваться вопросом о том, всё ли благополучно с вашим кодом. Может, стоить зарефакторить тот кусок программы, который вы только что прошли? После того, как вы перестали задавать себе вопросы о своём коде, у вас заработала фантазия, вы стали представлять себе то, как хуки будут смотреться в вашей кодовой базе.

Дальше вы ощутили непреодолимое желание всё же воспользоваться хуками. Вы обратились к тимлиду, или разослали сообщения всей команде, рассказали о новом замечательном подходе к решению задач, и выступили с предложением, в соответствии с которым вы начинаете работать по-новому.


Обложка выдуманной книги: «Переписываем фронтенд каждые шесть недель»

Несколько лет назад, в 2016 году, в твиттере @ThePracticalDev появилась обложка выдуманной книги. Тогда над постоянно меняющимся миром JavaScript шутили немного не так, как это делают сейчас.


Интерес к технологиям в августе 2016 года

Только никому не говорите: я изобрёл машину времени! Давайте по-быстрому смотаемся в 2016 год… Готово! Взглянем на то, как тогда выглядела экосистема JavaScript. Если вы применяли тогда некий JS-фреймворк, или только собирались применить один из них, то речь, вероятнее всего, шла бы об Angular. Но вот-вот должен был выйти Angular 2, что потребовало бы от вас переписать почти всё, что было написано в расчёте на Angular. Кроме того, в те времена набирала популярность новая технология — библиотека React. Конечно, тогда были и те, кто писал на чистом JS, и те, кто сознательно отказывался от фреймворков и библиотек. В 2016 году веб-разработка без фреймворков всё ещё была распространённым способом создания веб-проектов, но эта тенденция в те дни уже постепенно угасала.

Что бы вы сделали тогда, учтя вышесказанное? Какой бы путь вы выбрали и почему бы поступили именно так? Для вас, для человека из будущего, ответ на этот вопрос звучит совершенно очевидно: React. Но если бы вы выбрали тогда Angular, то через пару лет у вас бы возник соблазн использовать новую версию этого фреймворка и переписать свой код. Если бы вы выбрали React, то вам бы очень повезло. В наши дни буквально все «сидят» на React. А прямо сейчас вас неудержимо тянет отказаться от компонентов, основанных на классах, и перейти на функциональные компоненты, в которых можно пользоваться этими чудесными современными хуками. Так? Ну, это, по крайней мере, не значит, что вам придётся изучать целый новый API, как было при переходе с Angular.js на Angular 2. Верно?

Что делать разработчику при таком богатстве выбора и при вечной нехватке времени?

Неважно, на самом деле, что будет выбрано сейчас, или что мы выбрали несколько лет назад. В будущем у нас всё равно будет возникать или сильное желание, или необходимость переписывать старый код. У этого могут быть разные причины:

  • Компания использует [тут поставьте название фреймворка] и не может найти нужных ей специалистов.
  • Вы чувствуете, что старое решение вас больше не устраивает, в результате вам хочется чего-то нового.
  • Вы тянетесь за трендами и хотите пользоваться только самыми новыми и самыми лучшими технологиями.

Всё это будет так до тех пор, пока мы не разорвём порочный круг современных технологий.

Разрываем порочный круг


В самой основе нашей индустрии находится постоянное улучшение того, что уже существует, и постоянное создание чего-то нового, что лучше чем то, что есть сейчас. Нас постоянно подгоняет необходимость создавать решения, которые лучше прежних. Новое должно быть эффективнее, проще, привлекательнее, надёжнее старого. Тот, кто в наши дни пытается подорвать идею постоянного обучения и постоянного совершенствования навыков программиста, идёт против всего и против всех. Я пока не собираюсь об этом говорить. Вполне возможно, я ещё вернусь к этой теме.

Идея необходимости изучать что-то новое, сама по себе хороша, я её поддерживаю. Но тут у меня есть один вопрос. Как часто нужно изучать что-то новое? Если говорить о JavaScript, то в этой сфере очень часто появляется нечто такое, чего раньше не было: новые идеи, публикации, библиотеки, фреймворки… всего и не перечислишь. Когда нечто становится популярным, трендовым, программисты стремятся быстро внедрить это в свою работу. Я не говорю о том, что не надо пользоваться новым, и о том, что не надо подходить к решению задач с разных сторон. Я совершенно так не считаю. Я пытаюсь защитить идею, в соответствии с которой к новому стоит прибегать не так часто, как это делается в наши дни.

Давайте рассмотрим практический пример. Я пользовался axios, это — отличная библиотека. Её код хорошо покрыт тестами, она отличается широкой поддержкой, у неё много GitHub-звёзд и так далее. Однажды мне попалась публикация, в которой дана рекомендация о том, что от axios нужно отказаться, создав собственное решение для загрузки различных материалов.

После прочтения заглавия публикации, «Замена axios на простое собственное решение», читателю предлагается подробное описание процесса создания собственного решения, предназначенного для замены axios. Статья заставляет читателя задуматься о том, правильный ли он сделал выбор, используя axios.

Я не буду говорить о том, стоит или не стоит поступать так, как рекомендуется в той статье. Она сама хорошо раскрывает эту тему. Но я собираюсь помочь с процессом принятия решений тем, кто задаётся вопросами о том, надо ли им менять то, чем они пользуются, на что-то новое. Если говорить об axios, то решение по поводу этой библиотеки можно принять, задав себе несколько вопросов.

Вас, прямо сейчас, устраивает axios? Если вы ответите «да», то, вероятно, лучше отказаться от идеи замены axios на что-то другое. При использовании библиотеки axios оказалось, что у вашей команды возникают с ней сложности? Если это так — тогда попытайтесь поступить так, как сказано в вышеупомянутой статье, и выясните, устроит ли вас такой подход.

Если выразить мою рекомендацию в двух словах, то получится так: не ведитесь на хайп. Попытайтесь прислушаться к себе, поймите, что вам лучше всего подходит, и применяйте это. Постарайтесь не поддаваться новым сверкающим идеям из твитов, постов в блогах, из топов публикаций, из трендовых хештегов. Не позволяйте им управлять вашим поведением. Сейчас я расскажу о том, как этого избежать, о том, как перестать следовать методологии разработки, которую можно назвать «Hype Driven Development» (HDD), или «разработка, основанная на хайпе».

Разработка, основанная на хайпе


В индустрии разработки ПО хайп — это обычное дело. Помните NoSQL? Или время, когда все сходили с ума по микросервисам? Или взрыв интереса к искусственному интеллекту и машинному обучению? Людей увлекают новые, революционные технологии и идеи. В Gartner сделали прекрасную иллюстрацию того, что называется «циклом хайпа».


Цикл хайпа

Здесь показан типичный жизненный цикл новой перспективной технологии. Этот цикл включает в себя пять фаз:

  1. Инновационный триггер.
  2. Пик чрезмерных ожиданий.
  3. Избавление от иллюзий.
  4. Преодоление недостатков.
  5. Плато продуктивности.

Есть среди чего-то такого, чем вы пользуетесь сейчас, некая технология, жизненный цикл которой соответствует некоей части представленного здесь графика? Цикл хайпа можно представить и в более детализированном виде. Например, вот как это сделано здесь.


Более подробное описание жизненного цикла хайпа

Вспомните об этом графике, когда решите следовать новому JS-тренду, и подумайте о том, на какой стадии жизненного цикла хайпа этот тренд находится.

Выбор технологий в условиях хайпа


Хайп, воодушевление чем-то новым, это явления, которые иногда приносят пользу. Без них жизнь была бы скучной и безвкусной. Иногда может оказаться полезным освежиться и поддаться хайпу, но, прежде чем это сделать, стоит провести некоторые изыскания.

Вспоминайте об этом тогда, когда пытаетесь внедрить в свою работу какую-нибудь новейшую библиотеку или какой-нибудь страшно популярный фреймворк. Я предлагаю, принимая решение о внедрении чего-то нового, задаться некоторыми вопросами и провести некоторые исследования, о которых расскажу ниже.

▍Прежде чем принимать решения — исследуйте и протестируйте новую технологию


Чтение статей, твитов и пресс-релизов приносит определённую пользу при принятии решения о внедрении новой технологии, но для того чтобы точно понять, нужно вам что-то или нет, надо приобрести в этом некоторый опыт. Попытайтесь, используя новую технологию, создать прототип, реализующий основные моменты того, для чего вы эту технологию собираетесь использовать. Посмотрите на то, как этот прототип согласуется с остальными используемыми вами решениями.

Если вы планируете внедрить что-то новое в масштабах команды — попробуйте устроить что-то вроде командного хакатона. Подобные мероприятия очень хорошо показывают себя в деле командного тестирования новых технологий. На хакатонах можно свободно и креативно исследовать технологии. После мероприятия можно обсудить результаты с командой, выявить плюсы и минусы новой технологии.

▍Решает ли новая технология некую задачу, и если да — то какой ценой?


Есть ли у вас некая задача, которая уже как-то решена? Если так — подумайте о том, как решить эту задачу с помощью новой технологии. Сколько времени это займёт? Стоят ли выгоды, которые можно получить от этой технологии, времени, которое будет потрачено на её изучение и на переделывание существующего решения? Сильно ли внедрение этой технологии замедлит скорость разработки?

▍Поинтересуйтесь мнением других программистов


Если вы работаете в небольшой компании или в небольшой команде, члены которой не слишком опытны, то выполнить эту рекомендацию может быть непросто. Попытайтесь узнать о том, что думает о новой технологии кто-то вроде архитектора или старшего программиста. Дело в том, что то, что некая библиотека отлично показывает себя на сайте AirBnB, не значит, что она идеально подойдёт и вам. Возможно, вы, считая так, просто чего-то не учитываете. Если у вас есть возможность пообщаться с кем-то, кто опытнее вас, вам нужно непременно это сделать.

А что если вы — весьма опытный разработчик, так называемый «сеньор»? Если так — попытайтесь пообщаться с начинающим программистом, с «джуниором», или с кем-то, кто не так опытен, как вы. Многие компании применяют модель обучения сотрудников, называемую «обратным наставничеством» (reverse mentoring). Речь идёт о том, что джуниоры обучают сеньоров. Опыт сеньоров обменивается на свежие перспективные взгляды джуниоров. Попробовав обратное наставничество, вы очень удивитесь тому, сколь многому можете научиться, и тому, сколь многому можете научить других.

Итоги


В итоге хочу привести одну простую рекомендацию: «Постарайтесь не принимать поспешных решений относительно того, о чём вы только что узнали».

Сталкивались ли вы с негативными последствиями необдуманного применения популярных технологий?



RUVDS.com
RUVDS – хостинг VDS/VPS серверов

Похожие публикации

Комментарии 70

    +3
    Действительно, зачем использовать последние достижения оптимизации, зачем нам эти Vue, React, Flutter, если любое приложение можно написать на чистом Javascript самой первой версии — подумаешь, это всего лишь займет в 20 раз больше времени…

    Попробуйте написать комплексное кросс-платформенное приложение не на Flutter, а на чистом JS в одиночку за 1 месяц, и поймете что тренды не просто так появляются — на чистом JS у вас через месяц будет приложение готово только 5%, а на Flutter уже будет полноценное работоспособное красивое приложение, работающее на нескольких платформах
      +1
      а что, не на чистом JS можно за месяц серьезное приложение написать?
        +1

        Яро интересуюсь флаттером (в основном его с++-движком), но для веба ещё не оптимизирован.

          +1
          На мастере с FLUTTER_WEB_USE_SKIA=true работает уже очень плавно. Со скроллом и анимациями проблем вроде бы нет. Потенциал большой.
            +3

            Как мне кажется "на мастере с FLUTTER_WEB_USE_SKIA=true" означает, что технология находится в самом начале графика из статьи, и сама статья показывает, почему стоит избегать таких технологий, пока они не вырастут во что-то серьезное.

              +3
              Без тех, кто поддался хайпу, технология рискует не вырасти во что-то серьёзное. Новым технологиям нужны альфа-бета-тестеры :)
          0
          Тут скорее вопрос не в том, чтобы не пользоваться новым, а в том, чтобы не кидаться бездумно на хайповые тренды. Причин пользоваться менйстримом может быть много, но главная — все же это поддержка старых технологий, которые теряют свои экосистемы и потихоньку уходят и перестают поддерживаться. Но это больше об устаревание технологий чем об использовании новых.
          0
          На чистом js вы не напишите кроссплатформенное приложение без использования какого-л. фреймворка (или самостоятельного написания оного, но уже не на js), соотв. это упрощает задачу и получается, что вся разница лишь в языках js vs dart и flutter vs используемый фремворк. Поэтому сомневаюсь, что только 5% будет готово, как бы не 95, а то и все 100
            +7
            и поймете что тренды не просто так появляются

            Проблема не в том, что тренды появляются, а в том, что они часто меняются.
              +2
              Поправлю — «не работающее» нормально ни на одной из платформ.
                0
                Флаттеру уже года 2-3, Реакту так и вообще лет 6. Они никак не вписываются в «новомодные» технологии.
                  0

                  Так речь про фичи в них, нигде не говорилось, что реакт — "новомодная технология"

                  0
                  действительно, зачем использовать стабильные версии, если можно использовать самые новые тренды, которые сомнительного качества, с кучей багов и падением производительности?
                    +3
                    Пишу сайты на php+jquery, но однажды решил изучить что-то новое, мне порекомендовали Angular. Пока я читал документацию и продолжал делать сайты на jquery мне сказали, что Angular уже устарел и нужно использовать Angular2 потому, что он быстрее, но через некоторое время и Angular2 устарел и появился и что VUE значительно быстрее и лучше…
                    В результате, у меня сложилось впечатление, что новые веяния в JS, это не пригодное для маленьких компаний поделки требующие больших доработок. Продолжаю писать сайты на php+jquery.
                      +3
                      Vue появился 7 лет назад. Эта тройка фреймворков (вью, реакт, ангуляр) уже вышла на «плато продуктивности», как мне кажется. Это не значит, что надо от jquery отказываться — они решают разные задачи.
                        +1
                        php+jquery
                        Очень многое теряете с jQuery. Советую именно Vue для перехода с jquery. Он не такой монструозный как ангуляр, и начать можно с простого подключения cdn-скрипта (ну прям как в jquery!) вместо сборки полноценного билдера. Вы будете удивлены насколько проще делать большинство задач с помощью vue.
                          +1
                          вроде скоро vue3 выйдет, а если сейчас начать использовать vue2, тогда скоро придётся переходить на vue3?
                            +1
                            Да нет, vue2, вроде, не обещают при этом тут же задеприкейтить и забросить. Так что можно спокойно юзать.
                      +9
                      У реакт-хуков, раз уж статья затронула эту тему, масса недостатков. Я вернулся на классы и в массе случаев это удобней. Стоит ли сейчас писать статью на пике хайпа, чтобы триггернуть фазу «избавление от иллюзий»?
                        +7

                        Самое время

                          +4
                          Я п почитал
                            +4
                            Можете перечислить основные недостатки, которые заставили вас вернуться обратно на классы?
                              +2
                              Да, очень кратко аргументы приводил в этом треде, но без примеров реального кода и прямого сравнения альтернативных реализаций сложных компонентов выглядит недостаточно обоснованно. В целом можно разбить аргументы на семантические (синтаксис, основанный на соглашениях), анти-best-practice (смешение синхронного и асинхронного кода, сайд-эффекты в колбэках, раздувание чистых функций и смешение ответственности), сложностей в композиции (т.к. нет доступа к общим props и context, приходится передавать их в каждую функцию напрямую, что приводит к запутанному клубку), деградации перфоманса (т.к. приходится либо обкладывать многие части useCallback / useMemo, либо логика будет пересоздаваться на каждый ререндер и не будет работать сравнение по ссылкам).

                              Есть и плюсы, конечно, у этих хуков, но реализовав несколько проектов с очень сложными компонентами (с композицией десятков и сотен хуков), первоначальное желание с ними работать пропало. Я не готов обсуждать детально в комментариях эти аргументы сейчас, так как сам не проводил тщательное параллельное сравнение, это просто навскидку.
                                0

                                Несколько проектов с сотнями хуков — да вы не спите, что за год уже столько написали! (Хукам год)


                                А на практике, спагетти можно создать где угодно, сложный код вызван неумением компонировать, а не технологией.


                                Вот контекст был плохой идеей. Советую посмотреть https://www.youtube.com/watch?v=pn0pIgdQvhU для истории, может вы чего упускаете.

                                  0
                                  Почему же не сплю? При средней продуктивности 2к строк качественного кода в неделю сотня хуков набирается за рабочий месяц, при использовании хуков в виде замены классовых методов. Ну и побольше, чем год уже хукам, если статью по ним писал в апреле 2019 уже по релизной версии Реакта)
                                  Про мое умение компонировать сейчас не очень хочется говорить, если буду писать статью, то представлю полдесятка концептов композиции функций, но сделаю вывод, что по удобству разработки все они не дотягивают до классовых методов. Пока что тут нечего обсуждать.
                                  Посмотрел видео, про контекст там не говорится, там про передачу стейта несколькими путями, кроме контекста и инджекта, а я использую как раз последние в продуктовой разработке.
                                    0

                                    В видео Эрик в общем говорит о дизайн паттернах, контекст там упоминается как один из них, но он создаёт все тот же callback (context) hell, да ещё и неявный.


                                    Что у вас за хуки, я не понимаю откуда столько функционала?

                                      0
                                      context hell — это наверное при использовании их в иерархичном подходе вместо глобального? Тогда поддерживаю, это нелепость. Функционал разный — wysiwig, тултипы, селекты, графики и системы из них, сложные галереи с динамическими раскладками, таблицы со всякими сортировками-дозагрузками, календари ну и что там еще фронтенд-разработчикам прилетает. Стараюсь вникать в сложные проекты, так как и оплата там соответствующая, поэтому от недостатка количества функционала не страдаю — бывают документации по десяткам страниц на компонент и чтобы работало на десятках устройств с разным отображением)
                                        0
                                        иногда одним глобальным контекстом не обойдешься, например если есть кусок приложения которое вообще можно вынести как отдельное приложение, как у фейсбука (отсюда и пошли микрофронтенды). Плохо когда вложенные контексты лепят повсюду, пойди разберись что откуда пришло.

                                        Сотни хуков это вы про useState useEffect, я уж подумал у вас кастомные, извиняюсь. Ну, по личному опыту разве что с объектами в хуках я не люблю работать. И с предыдущим значением. В остальном все просто и плоско :)
                                          0
                                          При работе с асинхронно дозагружаемыми компонентами и их внутренним состоянием я предпочитаю мерджить его в глобальный стейт для универсальной схемы работы. То, что при загрузке 5 страниц (каждая из них — условно отдельный фронт) у меня будет единый стейт, в котором хранится их состояние, вместо 6 разных стейтов (на каждую страницу + рут) — это большое преимущество.

                                          Вообще я как раз про кастомные хуки говорил) Бывает длиннющая цепочка из полусотни, кроме шуток, и «плоско» — это только на верхнем уровне, то есть в функции рендера, в то время как если распутать весь клубок, получится множество взаимосвязей и изменений одних и тех же параметров.

                                            useOnOpen(params);
                                            useScrollToCurrentOption(params);
                                            useClickOutside(params.selectRef, () => handleOutsideClick(params));
                                            useSetValidation(params);
                                            useDisabledChange(params);
                                          
                                  +1
                                  С начала 2020-го постепенно, осторожно перевожу существующие проекты на хуки, но еще пока рискую начинать использовать их в новых (больше из-за того, что начинает страдать скорость разработки). И пока остается redux с коннекторами, еще более-менее приятно работать с глоб. стейтом. Но когда пытаюсь избавиться от него в пользу контекста с селекторами (хуками), то сталкиваюсь с тем, что вы написали выше: длинный перечень useCallback/useMemo. Пытаюсь скомпоновать. Плохо удается.

                                  Продолжаю лопатить статью за статьей, читаю рецепты, копаюсь в шаблонах сторонних проектов. Ваш коммент заставляет задуматься.
                                    0

                                    Я вот смотрю в сторону effector, как замену redux. Пока только на пэт проекте пробую — вроде все хорошо.

                                  0
                                  Можно как минимум попробовать поработать с youtube API, который работает на классах. Почему-то мне так и не удалось создать экземпляр и потом с ним нормально работать в хуке.

                                  Не исключаю, что мои руки виноваты, но тем не менее. На классах все прекрасно работало…
                                  0
                                  Я бы почитал про массу недостатков. Можно прямо здесь.
                                  +2
                                  Моя карьера «чистого и серьезного» программиста началась в 30 лет.

                                  До этого было много всего, начиная от различных не-ИТ-профессий, и заканчивая SEO/маркетингом в том же ИТ.

                                  И знаете что бросается в глаза, при переходе в коллективы программистов? Что сложно себе представить более подверженных маркетингу людей, чем программистов. Не знаю с чем это связано, но вот складывается впечатление, что банальная, базовая защита от всяких там «купи-купи, вам это подойдет», которая есть у каждого современного человека, у программистов напрочь отсутствует.

                                  Выходит какая-то новая технология. Маркетолог пишет продающий текст о том, какая она классная — и программисты воспринимают это за чистую правду. И не просто бегут пробовать и внедрять эту технологию, а начинают агитировать всех окружающих.

                                  P.S.
                                  С чем это связано — для меня загадка. Может быть, так решается внутреннее желание отрефакторить старый код. Ведь если просто сказать — «надо все переписать» — то нужно будет признать, что код был плохой (и сразу падает тень на тех, кто его писал). А если рефакторинг делается под предлогом «монолит это плохо, вот сейчас все перепишем на микросервисы и будет круто» — то звучит уже не так стыдно.
                                    +5
                                    Мне кажется Вы немножко путаете причину и следствие.

                                    Представлю мою гипотезу про «с чем это связано».

                                    На ранних этапах карьеры — это естественный отбор.
                                    Программистами в результате остаются те, кто любит это дело, а не те кто радеют о бизнесе.
                                    Бежать пробовать и внедрять технологии они бегут из любви к технологиям, а не потому что мозги промыли. Да, разумеется маркетологи влияют на то какую именно технологию бежит пробовать неофит, но ни в коей мере не пробуждает сам порыв.

                                    Во вторых когда ты молодой и неопытный, у тебя еще нет любимого инструмента. Технологии в которых еще никто не разбирается выглядят более многообещающе на эту роль. И если ты внезапно стал главным спецом по %технология_икс% то чем больше эта технология применяется, тем больше твоя личная роль. Потому и агитируешь.

                                    После получения лычки сеньора это уже в основном осознанный выбор.
                                    Технологии меняются очень быстро, твой любимый инструмент тоже обречен на устаревание когда-либо. Поэтому постоянно надо пробовать что-то новое, хоть и в разумных пределах. Просто если бизнес этой необходимости не понимает, то хайповые технологии легче бизнесу продать. Маркетинг в этом случае действует не на программистов, а на бизнес.

                                    То есть мне кажется что Вы заблуждаетесь, считая что программисты больше подвержены маркетингу. Не больше. Просто иногда следовать за рынком — выгодно для карьеры.
                                      0
                                      Потому что у программистов не маркетологи, а евангелисты и технолоджи-адвокаты. Они, в отличие от маркетологов, разбираются в том, что продвигают и сами это используют.
                                      –1

                                      Хороший абзац с очень известной технической книги, про преждевременные решения


                                      По теме статьи – если брать шире, речь вообще не про хайп, а про архитектуру решений.


                                      Люди пользуются инструментами чтобы решать задачи быстро и качественно. Проблема в том, что в современных приложениях почти отсутствует проектирование архитектуры, потому что поставляются сильно связанные решения (тот же Angular и его экосистема). Эти Реакты, Vue, и прочее должны быть заменяемыми инструментами в решении, как и axios, чтобы в случае проблемы с инструментов его можно было просто заменить без переписывания системы.


                                      Фактически сейчас приложения сильно зависят от самих инструментов, и именно поэтому как только инструмент становится легаси, так и всё приложение технически становится легаси, потому что без замены инструменты вывести его из этого состояния нельзя.


                                      С другой стороны, архитектура в которую впишутся все фреймворки, библиотеки, это космическая фантастика, и так, очень вероятно, не получится.


                                      Поэтому, имхо, нужно работать на трендовом инструменте, пытаясь по-возможности выкрутить опции в сторону абстракции.

                                        +1
                                        > Хороший абзац с очень известной технической книги

                                        Вроде бы абзац ИЗ книги, а не С?

                                        Просто достала глобальная замена «из» -> «с». «Стрелять с автомата», «сделанные со старых автомобильных шин» и т.д.
                                          –1

                                          Обычно обращаю внимание на мелочи в орфографии, но про это даже не знал, спасибо! )

                                        0
                                        Все таки переходить стоит, просто запланированно, а не стихийно

                                        Есть сейчас достаточно большое приложение на RN, переход на useEffect вместо componentDidUpdate позволяет все таки сделать код гораздо чище

                                        Просто решили так
                                        — Сначала, когда нужно внести правку в какой-то из компонентов UiKit переводим его на функциональный стиль
                                        — Затем, понемногу, переписываем все экраны.

                                        А переходить со связки Redux/Redux-Saga на какой-нибудь Recoil смысла нет вообще

                                          0
                                          Recoil так же не понравился.
                                          Что скажете на счет effector?
                                            0
                                            Есть одна штука, вот такой код просто пишете и это работает.
                                            this.isFetching = true;
                                            const response = await apiRequest(`GET /items`);
                                            this.items = response.items; 
                                            this.isFetching = false;
                                            

                                            Что скажете?
                                              0

                                              Не совсем понял к чему это

                                                0
                                                Вы хотите писать вот такой код и чтобы все работало?
                                                fetchData = async () => {
                                                     // Компонент который использует эту переменную перерендеривается и показывается  лоадер
                                                    this.isFetching = true;
                                                    // Получаем список чего-нибудь из АПИ
                                                    const response = await apiRequest(`GET /items`);
                                                     // Компонент который использует эту переменную теперь имеет данные для     
                                                    рендера
                                                    this.items = response.items; 
                                                     // Компонент который использует эту переменную перерендеривается и убирает     лоадер и выводит список из переменной items
                                                    this.isFetching = false;
                                                }
                                                
                                                  0

                                                  Как это касается моего вопроса?)
                                                  Если знаете подводные камни effector — буду рад услышать, что бы опробовать самому.
                                                  То, что вы сторонник mobx я уже понял)
                                                  Но пока что он меня так не впечатлил.

                                                    0
                                                    То есть это избыточно, сложно и т.п. да? А в effector все гораздо проще и компактнее?
                                                    this.isFetching = true;
                                                    const response = await apiRequest(`GET /items`);
                                                    this.items = response.items; 
                                                    this.isFetching = false;
                                                    
                                                      0

                                                      Я не говорил проще, и я не говорил компактнее (хотя скорее всего так и есть).
                                                      Если вы хотите сказать, что в mobx компактнее — окей)


                                                      По существу — вы сталкивались с подводными камнями в effector? Поделитесь таковыми, пожалуйста.

                                                        0
                                                        Таки смысл использовать заранее кастрированный и неудобный инструмент? Когда есть тот, который решен этих недостатков.
                                                        Подводные камни — иммутабилен, неудобен в использовании, примитивен как палка, уровень раскрытия возможностей JS — 0%.
                                                        Если вы хотите поднасрать кому нибудь в проект, то да, притащить это будет хорошая идея.
                                                          0
                                                          В чем неудобство и кастрированость то собственно?)
                                                          Иммутабелен
                                                          не уверен, что это минус.
                                                          Неудобен в использовании
                                                          субъективное суждение
                                                          Примитивен, как палка
                                                          так вы определитесь, он либо сложный, либо примитивен, как палка)
                                                          Уровень раскрытия возможностей JS — 0%.
                                                          почему не -100% ?)

                                                          Ну и к слову, стоит ожидать от вас статьи «effector vs mobx vs ...»?
                                                          С удовольствием бы прочел!
                                                            –1
                                                            В чем неудобство и кастрированость то собственно?)

                                                            Если для вас это не очевидно, то извиняйте, разговор ни о чем) Тем более вы говорите что знакомы с MobX и имеете такое мнение, для меня это нонсанс) Видать все таки не знакомы на самом деле.
                                                              0
                                                              И снова вы за своё?) Зачем выдавать свои субъективные суждения за данность?)

                                                              Где я говорил, что знаком с mobx?
                                                              Я вообще говорил, что mobx плох?)
                                                                0
                                                                Перепутал вас с другим, тоже про effector спрашивал, ну не суть) Тем более вы даже не познакомились с другими решениями для управления состоянием. Если бы познакомились не было бы вообще этого треда)
                                                                  0
                                                                  Так я и знакомлюсь — в этом же и была суть моего вопроса) Я смотрю варианты и пробую.

                                                                  Стоит ожидать от вас статьи-сравнения?) А то пока что аргументов против толком не было — только вкусовщина.
                                                                    +1
                                                                    Писать статьи лень, гораздо быстрее будет вам понять что лучше/удобнее и т.п. Это просто сделать аналоги
                                                                    Раз
                                                                    codesandbox.io/s/interesting-snyder-v8k4o
                                                                    И два
                                                                    codesandbox.io/s/affectionate-keldysh-7mpwt

                                                                    На effector'e и вообще на чем душе угодно и сравнить код с MobX'овским и сделаете выводы
                                                                      0
                                                                      Касательно раз вот
                                                                      codesandbox.io/s/effector-example-tudc7?file=/src/App.jsx
                                                                      Касательно два потом как-то сделаю.
                                                                      И отмечу, что effector я только изучаю — возможно есть ещё более элегантные решения, о которых я пока не знаю.
                                                                        0
                                                                        Вы не разделили строны на глобальный и локальный, у вас оба стора глобальные.

                                                                        Вариант два я думаю вы так и не сделаете, потому что он не такой мега простой и банальный, и на effector'e вам уже гарантированно не понравится реализация)

                                                                        А так в целом уже посмотрите на код, ведь очевидно насколько effector выглядит нелепо по сравнению с MobX и это на супер простом и банальном примере не имеющим отношения к реальной жизни, толи было бы хотя бы с примером номер два, который вы не сделали, вот там будет конкретный вырвиглаз) И не забываем, понятия локального стейта и глобального разные, это не одно и то же)
                                                                          0

                                                                          Исходя из вашего комментария, я понимаю, что effector вы даже не пробовали. Почитайте хотя бы о его концепциях.
                                                                          И мне непонятно, зачем тогда effector везде хаять и превозносить mobx?

                                                                            0
                                                                            Моего опыта с 2012 года с головой хватает, чтобы без применения чего-либо в реальном проекте понимать хлам это или нет. Effector это чистый воды хлам.
                                                                            Код говорит сам за себя. Такое просто противопоказано применять не в одноразовых проектах где работает более одного человека.
                                                                            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, и то и другое машина и то и другое может довести от точки А в точку Б, но то как они тебя повезут, и то какие технологии применены, тут уже целая пропасть между ними.
                                                                              0
                                                                              Исходя из ваших ответов — вам все равно что за технология, потому что вы знаете mobx и он автоматически лучше.
                                                                              Вы своё субъективное мнение выставляете за данность уже, в который раз.

                                                                              Вы не пробовали, вы даже не удосужились почитать хотя бы о базовых принципах effector, но уже заклеймили.

                                                                              Так о каком опыте вы говорите? Беспочвенного хейтерства?
                                                                              Из разряда:«Красные ягоды несладкие — вот я пробовал клюкву, и она была кислой. Так что клубника так же кислая — не ешьте.»

                                                                              Количество символов? Вы серьёзно? Более веского аргумента нету? Ах да, вы ж не пробовали — у вас эфемерный опыт.
                                                                              И так же вы сами решили, что он не реактивный — ну, у вас же опыт.

                                                                              И как бы effector появился позже чем mobx, так что еще вопрос, кто тут tesla.
                                                                              И tesla так же сперва не воспринимали всерьёз )…

                                                                              Но вы и далее продолжайте хейтить то, с чем даже не ознакамливались.

                                                                              На этом, я считаю, наш диалог окончен. Удачи)
                                                                                +1
                                                                                Лол, удачи) Как я уже ранее говорил, если для вас не очевидно что Effector это дно, то увы и ах)
                                                                                  0
                                                                                  С вашей «очевидностью» без аргументов — спасибо. Пожалуй, такая очевидность мне не нужна.

                                                                                  Во всех инструментах есть плюсы и минусы. Вы же настолько превозносите один инструмент, что даже не разбираетесь с другими. Ну, удачи)
                                                                                    –1
                                                                                    Удачи обосрать кому нибудь проект притащив туда Effector или любой подобный инструмент (они все плюс минус одинаковые, поэтому и относятся к классу «очередной хлам»), учитесь на своих ошибках, мне то что, мне с вами на одном проекте не работать =) Я думаю если вы купите машину с кондиционером, то в жару вы им не будете пользоваться, вам и так будет нормально) Вот такая же аналогия, JS вам дает просто уйму возможностей, а вы используете каплю из этого преднамеренно, попахивает мазохизмом конечно)
                                                                                      –1
                                                                                      Вы прям, как заложник одной технологии. Что ж вы такой заскорузлый?
                                                                                      Аргументов не наводите, зато желчь аж хлещет.
                                                                                        –1
                                                                                        Удачи)
                                                            0
                                                            Всё очень спорно;

                                                            иммутабилен — это плюс, когда бэкенд весь иммутабилен,
                                                            и не надо туда-сюда голову перекючать ради 5% кода на js;

                                                            чем более примитивен инструмент, тем проще понять, как он внутри работает;

                                                            mobx работает как-бы _интуитивно_, но понять, как он _точно_ работает скорее всего будет сложней;
                                                            не все модные возможности JS хочется раскрывать, начиная от слетающего «this», и заканчивая прокси, когда написано одно короткое выражение, а отрабатывает хитрая магия.

                                                            Ну, если писать на mobx ежедневно, то возможно есть смысл со всем этим хорошенько разобраться и печатать на 25% символов меньше.

                                                            Или тут какие-то принципиальные бонусы?

                                                            Если что, я сам пока ни того, ни другого не выбрал.
                                            +4
                                            По-моему, статья подходит к вопросу односторонне: со стороны производителя продукта, его интересов. А потому оценивает переход на новые технологии исключительно с точки зрения того, как они могут улучшить (читай — удешевить) разработку и сопровождение продукта (ну, или повысить его продажи).
                                            Однако большинство программистов являются не производителями, а немными работниками, работающими на производителя. Поэтому объем продаж продукта и оптимизация затрат находятся, в лучшем случае, вне круга их материальных интересов. Интерес у них другой — поднять свою цену на рынке труда. А факт владения модной технологией при прочих равных условиях поднимает эту цену, и весьма заметно.
                                            Так что для программистов, работающих по найму есть прямой материальный смысл следовать модным трендам, несмотря на все те аргументы, которые приводятся в статье.
                                              0
                                              Автор, рекомендую посмотреть определение слова «тренд» в вики или в словаре. «Тренд» — это основная тенденция (в отрасли, в данном случае). Так в чем основной посыл статьи — следовать или нет основным течениям в отрасли? Конечно да, следовать. «Хайп» и «тренд» — это скорее противоположные по смыслу понятия. А пока, уж извините, я слабо понимаю о чем статья.
                                                0
                                                Идея понятна, но пример неудачный. Замена axios на fetch позволяет сэкономить 5 гзипованных кб.
                                                  0
                                                  Давайте рассмотрим практический пример. Я пользовался axios, это — отличная библиотека. Её код хорошо покрыт тестами, она отличается широкой поддержкой, у неё много GitHub-звёзд и так далее. Однажды мне попалась публикация, в которой дана рекомендация о том, что от axios нужно отказаться, создав собственное решение для загрузки различных материалов.

                                                  Мне кажется тут скорее проблема у самого автора.
                                                    0
                                                    *Следит с попкорном и колой*

                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                    Самое читаемое