Комментарии 103
Я не понял смысл поста. Просто пожаловаться, что не дали воткнуть велосипед, который, я уверен, имеет далеко не самый хороший API? А потом как это поддерживать? Учитывая, что React из коробки имеет просто отличный state management, заточенный под React…

Смотрит разработчик на код и спрашивает — "а кааак это поддерживать?".


Тонны редакс-быдлокода, написанные в режиме "главное завалить а там ногами запинаем" мы не спрашиваем как поддерживать. А небольшой, но свой стейт-менеджмент в 500 строк кода суммарно — всё, проблема проблем! Мы не знаем что делать кроме как рыдать "спаситипамагити мамочка тут велосипед!", "да, мы видим его код, мы знаем буквы которыми он написан, мы знаем язык на котором он написан но ОООО УЖАС КАК ЖЕ ЭТО ПОДДЕРЖИВАТЬ?!".


И действительно. Неподвластная человеческому уму задача.


P.S: а вы часто смотрите в код пакетов, которые вы используете? А количество открытых issues? А когда был последний коммит — тоже проверяете? А документацию на сайте с API сопоставляете (вдруг там не всё описано)? А как вы будете поддерживать своё приложение если завтра автора вашего, конечно же, не-велосипедного пакета из npm собьёт автобус вы часто спрашиваете?

У меня есть история на эту тему. Прикручивал я mobx к angular. Взял mobx-angular, который использовал недокументированное апи, чтобы подцепиться к ангуляру. Ни у кого вопросов не возникло, ведь это сторонний пакет.


Но решил я его улучшить, добавив поддержку SuspenseAPI, поэтому форкнул, чуть упростил и добавил эту фичу. Кода там с гулькин нос. То теперь это (о ужас!) использование недокументированного апи в нашем репозитории. В результате этот пулреквест пришлось откатить и написать кучу бойлерплейта из-за отсутствия SuspenseAPI.

Ага, в нерабочее время. Да и в любом случае бы зарубили ибо "слишком мало звёзд на гитхабе".

А мы часто решаем проблемы от сторонних решений. Процентов 70 головной боли именно от сторонних библиотек. И решение, зачастую, приходит из таких же болей разрабов на ближайшем stack overflow. Соответственно если мы используем библиотеку которую написал и использовал один средний Столман, то и проблему решать мы будем исключительно в две головы. В случае кончины автора — в одну.
P.S: а вы часто смотрите в код пакетов, которые вы используете? А количество открытых issues? А когда был последний коммит — тоже проверяете? А документацию на сайте с API сопоставляете (вдруг там не всё описано)? А как вы будете поддерживать своё приложение если завтра автора вашего, конечно же, не-велосипедного пакета из npm собьёт автобус вы часто спрашиваете?

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

На самом деле, довольно просто: если компания энтерпрайз, может быть текучка, то, конечно, любой говнокод на редаксе лучше, чем на велосипеде. Learning Curve, там.
Но на практике, есть разработчики, которые не могут разобраться даже в Redux. Для них middleware — это магия высшего порядка, код, написанный сеньерами для лидов.
Dependency Injection? Conversion of control? Вы што?


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

Это когда зависимости не только не приносят проблем, но ещё и приносят доход! Святой грааль разработки.

Коллеги рекомендуют чаще сливаться со стволом, чтобы избежать проблем с зависимостями.


image

Когда времени мало и нужно решить какую либо фундаментальную проблему, то можно отдать приоритет велосипеду.
Из примера
Есть Андроид с его фрагментами и идиостким апи перехода:
взять активити, достать фрагмент менеджера, создать фрагмент, сказать фрагмент менеджеру возьми этот фрегмент пихни во вью, пихни в стек, дай ему тег, если надо.
А если в верстке есть косяк или дизайн что то требует (показать тул бар, скрыть таббар) при переходе в фрагменты, то нужно дотягиваться до активити при переходе. Кто с этим работал, тот видел весь этот говнокод смены фрагментов в чужих проектах (вызов этого апи из адаптеров списков, например) :)
Жуть.
Есть библиотеки состояний с развитым апи, там текста инструкций больше чем надо кода.
Определить интерфейс сможет и джун: Вперед, назад, назад в корень, заменить.
Навесить пару паттернов состояний (forward/bacward):
И вот за час рождается библа, которая с 2016 (создана 2016‑11‑24) года поменяла поменяла только положение переменных в вызове какого то метода.
Т.е. на создание такого велосипеда ушло меньше времени чем на изучение и внедрение существующих и данная либа ушла проектов в 20-30.

А вот вся эта мишура с развитым апи, гибкостью и другими штуками очень часто не нужна.
одобряю за подход «выстрелил — забыл»
в смысле, чем проще либа, тем лучше
React Context + React Hooks или Redux — этого достаточно для решения большинства задач. Написать свою либу для управления состоянием вы можете конечно, но кто это будет поддерживать после вас?
Использование читсого реакт апи многие тоже величают велосипедом — ведь есть же редакс
Core-разработчики React, в числе которых авторы Redux, уже как 100 лет говорят, что Redux неактуален для большинства проектов. React сам по себе имеет отличный state-management © sebmarkbage, kentcdodds, mjackson, rflorence, aclark
Осталось объяснить это всем компаниям, которые выкладывают вакансии React+Redux, и проблема исчезнет
Смешно, вы им правда пользуетесь? То есть вот прям реально?
— Так, я хочу шаг назад… Ой, флаг is_fetching откатился, ладно, хочу ещё назад, ой флаг is_fetching у другого объекта стора откатился, да что ты будешь делать… Ведь это же такая фича просто жизненно необходимая, а не работает на практике, какой кошмар.

Time Travel через механизм Undo/Redo сделать легко. А вот сделать механизм Undo/Redo через Redux — сложно.

Если в вашем конфетном мире существует только React 16+, то мои вам поздравления.

Голый react или react + redux это полный шлак, тогда уж гораздо лучше Vue или Svelte, а вот React + MobX это совсем другой разговор.

А это как стартапы — надо ли создавать свою компанию? Да вы что, это же дикий геморрой и 95% шанс прогореть и потратить время просто так, просто работать в корпорации куда надежнее и безопаснее. Но да, все существующие компании когда-то были стартапами…


Та же история с велосипедами. 95% или 99% оказываются субстанцией, но иногда что-то взлетает.


Более того, та же примерно история с собеседованиями. 95% кандидатов не проходят интервью — в принципе, логично было бы их и не проводить с таким процентом. Но другого варианта нет.

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

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

Ну и про процессы странное предложение в тексте. Я против бюрократии, но процессы точно нужны, если разработчиков > 1.

Бизнес может банально упереться рогом и не дать достаточно времени на нормальную реализацию очередной фичи, которая резко стала нужна ещё вчера. Бизнес может со временем изменить или добавить хотелки так, что некоторые вещи имеет смысл отрефакторить прямо сейчас дабы потом не наращивать тонны плохого и/или однотипного кода.


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

Разработчик может банально упереться рогом и делать элементарную вещь месяцами, которая резко стала нужна ещё вчера. Разработчики могут закладывать в сроки то, что не имеет смысла и не понадобится многие десятилетия.

Ничего не напоминает? А я такое вижу чаще, чем «бизнес, который требует вчера».

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

Так об этом и речь. Бизнес платит за «хотелки», разрабочик их реализует как считает правильным. Всё хорошо? Да.

А теперь разработчик приходит и говорит биизнесу: следующие полмесяца-месяц будешь платить за то, что я хочу делать, а не за то, что тебе надо. Нормально? Думаю нет.

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

Это абсурд. Бизнес и только бизнес решает какие задачи берутся в спринт, а какие будут в беклоге лежать месяцы и годы. Что там разработчик может решать в этом смысле?
То есть если бизнес игнорит задачи по рефакторингу, то он сам и гробит свой проект.
Если же он форсит писать быстрее и не дает разработчику достаточно времени на нормальную реализацию очередной фичи — происходит тоже самое, гробится проект, превращаясь в неподдерживаемое нечто.
превращаясь в неподдерживаемое нечто

Верно и потом уже делается версия 2.0 с полного нуля уже основательно и с головой. Ибо ни один уважающий себя разраб не будет в говне ковыряться. Я уже много проектов делал «2.0» с полного нуля, т.к. то, что было, было не пригодно к существованию от слова совсем. Но мне то что, мне по кайфу с нуля писать.

По нынешним временам всё чаще встречается переделывание не с полного ноля сразу, а поэтапно через вынос в сервисы/микросервисы.

Я куда чаще наблюдал отсутствие всяких 2.0, а адекватные разработчики вместо этого просто уходят с проекта/из компании, что приводит к отбору тех, кому 1.0 с говном внутри норм, что усиливает причины для отсутствия 2.0.

А ещё… 2.0 по качеству зависят от авторов их написавших)). С учётом, что переписывать самому свой код(если его много) много кто не любит, так как тема баян, то вырисовывается интересная картина. вероятно разработчик будет рандомный и по теории вероятности RICH аппликэйшены вероятно превратятся в говно.
P.S. фичу проектом называть не хочу. Фичу можно выкинуть и переписать.
Для малых проектов рано говорить про неподдерживаемое нечто(оцениваю величину, в оптимальном кол-ве строк java кода, да, и на это есть причины: На руби как-то в 30 строк без экстрима умудрился сделать фичу, но при добавлении функционала на 5 строк — пришлось переписать всё в 200. На java не сократишь особо, если не юзать норм архитектуру).

Так вот для средне-больших и больше проектов — не верю что переписать — решает проблемы заказчика. Заказчик помнит необходимых требований около 30% от реализованных(любил читать код при рефакторинге), если не документировал постоянно, особенно когда куча разных фич и их комбинаций. Так и будете по кругу переписывать, или рефакторить(уже свой код) по мере «вспоминания требований».
Хотя стойте, первопричина в отсутствии времени(а значит и лишних денег тоже).., а значит вы уже ускакали после заказа. Заказчику, конечно, стыдно послать всех и за всё вдогонку, но знайте это.
Если же денег хватает, то вот и аргумент за своевременный рефакторинг, и сказка, что скупой(заказчик) платит уже трижды.
Мы платим вам за то, чтобы вы косили траву. Времени на заточку косы в вашем трудовом договоре не предусмотрено.
Бизнесу с таким подходом — удачи, она ему понадобится.
А если разработчики пишут такой код, что его надо через неделю переписывать — повод задуматься, верно?

Почему через неделю, а не на следующий день? На "следующий день" было бы больше поводов задуматься, верно?

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

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

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

И вроде всё понятно, но осадочек остался

Люблю делать велосипеды в своих pet-проектах. Если сталкиваюсь с какими-то фундаментальными проблемами — разбираюсь, как сделано "под капотом" в других решениях. В итоге получаю кучу опыта и понимание возможных подходов.


Например, когда я осваивал 3д графику, написал свой код для векторов, матриц и кватернионов. В процессе собрал все грабли и досконально разобрался. После этого я могу взять любую библиотеку, использовать её на 100% и при необходимости дописать недостающую функциональность.


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

Давайте наведем наш телескоп на чуть-чуть другую планету. К примеру ваша позиция не подразумевает карьерного или профессионального роста, а ведь на собесе обещалось. И тогда прог вводит в свою кузницу микроскопы, разнообразные, а главное, востребованные.
— Карго культ, говорите Вы? — хехе, смотрит прог на Вас с прищуром ).
Проблеме не в конструкции самого велосипеда, а в разных мелких удобствах, которые по отдельности совершенно не принципиальны, но когда их становится очень много, то они выводят этот самый велосипед на принципиально более высокий уровень.

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

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

Автора прекрасно понимаю, так как сам сделал похожий “велосипед” (только под Ангуляр). И статью про его принципы написал. И хотел даже сделать её перевод на Хабре, но пока не решился, поскольку опасаюсь описанной автором реакции.


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


С другой стороны, принцип “авторитета” отнюдь не плох, так как попросту позволяет экономить время, не тратя его на подробный анализ тысяч схожих “поделок”. Возможно, среди этих “поделок” на самом деле есть “брильянты”, тщательно обработанные их авторами, но их мало и шанс найти что-то выдающееся невелик, поэтому и берут известное решение так как оно в 99% случаев не будет самым худшим, а в 99% случаев это и достаточно.

Есть ощущение, что основной массы негатива можно избежать, если в первых же абзацах readme.md описать, какие именно насущные проблемы решает ваша библиотека, и почему те же самые проблемы гораздо неудобнее / сложнее / дороже решать, используя более популярные библиотеки от больших игроков.

Как говорится, haters gonna hate, но адекватные люди, увидев понятное рациональное обоснование, вряд ли станут критиковать пусть и нишевое, но решение, нацеленное на конкретные и объективно существующие недостатки.

Не просто какие проблемы решает, а в какой именно нише.

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

Последняя мысль уже может быть признаком выгорания

Тут было бы уместно спросить чем велосипед отличается от продукта. Вроде бы тот же программный код, разработчиков у продукта может быть даже меньше, чем у велосипеда. То есть те кто не хотят велосипеда — чего они не хотят? На мой взгляд не хотят отсутствия документации, отсутствия версионирования и минимальной обратной совместимости, отсутствия поддержки, отсутствия вменяемой загрузки через регистр (например через npm, pip, composer), отсутствтвия нужных для разработки API и должного тестирования, проблем с производительностью которые "внезапно" вылазят на проде, подводных камней на которые наскакиваешь когда половина проекта уже сделана и спрыгнуть с "велосипеда" уже нельзя. А в остальном — все хорошо.

Дуглас Крокфорд изобрёл JSON. Некомпетентный болван похоже не знал, что у нас уже есть XML.

SGML
XML — это подмножество SGML, разработанное для упрощения процесса машинного разбора документа.
Некомпетентный болваны создали XML, когда не смогли справиться с SGML.
И далее по индукции…

Пример не корректный. Как в случае с xml так и в случае json авторы занимались разработкой стандарта, фактически документации. Корректным примером было бы если бы некий гипотетический автор реализовал метод xmlserialize и xmlserialize для объектов и включил это в проект без описания протокола сериализации и десериализации. Это был бы классичекий велосипед. И от был бы вреден так как никто не понимал бы как работает "эта магия'. И как поддержкивать этот проект.

Велосипедостроители бывают разные и причины у них разные


  1. Не разобрался как это работает и решил что может лучше. Результат как правило хуже, но автор отказывается в это верить.
  2. Разобрался как это работает, но не разобрался почему и для чего (не знает домена(во)) в которых используется инструмент, не знает даже своего домена. Результат — велосипед, который вроде как хорош, но на практике куча геморроя.
  3. Прошёл этапы 1 и 2, стал экспертом в области и запилил свой велосипед, который оказался лучше существующих.

Я не знаю, что за инструмент вы сделали, знаю только, что редакс это редкостное г… но, в котором есть здравые идеи. Ваша мотивация мне понятна. К сожалению русскоязычное коммьюнити очень злое. Я бы сразу писал все на английском и рассказывал об инструменте на HN и Reddit. Так будет больше шансов получить позитив. Только там другая проблема — вам скажут «все круто, давно хотел такую штуку, вот бы ещё там было X и Y» Вы можете броситься ее делать, а вам это написали просто из вежливости.


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

По мотивации я встречал такие варианты.


  1. Амбициозный. Хотели сделать продукт получился велосипед
  2. Ленивый. Есть готовая библиотека но нет желания ее изучать. Потом велосипед.
  3. Горе от ума. Например 99% разработчиков считают что использовать напрямую методы библиотек это неправильно. Нужно писать свои обертки которые якобы упрощают разработку. Например редко встретишь когда будет использован библиотечных метод отправки почты send. Обязательно нужно написать свою обертки которая берет гдето адреса, шаблоны и т.п. обычно весь этот хлам сбрасывается в каталоги helpers или utils.
Дуглас Крокфорд изобрёл JSON. Некомпетентный болван похоже не знал, что у нас уже есть XML.

Это крайне близорукое утверждение, оно никак не подкрепляет ваш тезис. XML набирал популярность вместе с Web 1.0, начиная с 1995 года. В то время кода на JS было очень мало, зато много писали HTML. Довольно разумным казалось сделать гибкий и похожий на HTML язык для описания данных.


JSON появился в 2001 году, кода на JS было уже сильно больше и этот код был главным потребителем XML. Уже стало понятно, что 99% данных форматируются очень просто, а гибкость XML оказалась невостребованной. Логичным стало поменять формат данных на урезанный JS, браузеры его уже и так понимали. Это особенно было хорошо для штук вроде JSONP, web sockets тогда еще не было.


Итого и XML и JSON логично вытекали из потребностей времени. Крокфорд не гений, идеи и так витали в воздухе, он оказался авторитетом, который озвучил их и получил себе славу первооткрывателя. Уверен, что менее популярные люди высказывали аналогичные идеи чуть раньше, просто им не повезло.

насколько я помню JSON стал популярен во время взлета популярности AJAX. бекенд мог отдавать данные в виде JSON, а клиентскому коду на javascript не надо его десериализовывать или маршаллить. Простой result = eval(jsondata) конвертировал json в чистый объект javascript, так что JSON появился как грязный хак веб-кодера, который использовал eval() яваскрипта для десериализации.

Времена ajax пришли немного позже. По поводу гибкости xml у него есть один недостаток. В нем сложно хранить массивы. При этом не различаются массива состоящие из одного элемента и объект если нет схемы документа. Кроме того каждый элемент массива должен иметь имя что также приводит к избыточности. Например
House
Appartments
Appartment
1
Appartment
2


В этом смысле json оказался даже гибче и в некотором смысле мощнее xml

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

противоположный подход это «кодинг по индусски» — прицепить сотни мегабайт .jar-ов и прочих сторонних библиотек чтобы 50 строчек из стековерфлоу заработали, когда можно было сделать нормально.
Я тоже написал свой велосипед вместо redux, т.к. он на практике не понравился. И мой велосипед в 10 раз лучше их велосипедов. Но я его тихо использую и никому не говорю, боясь показаться «велосипедостроителем», из-за миллиона хейтеров которые набегают первыми.

А ваш велосипед хорошо документирован? А что если потребуется расширение? Какой порог входа в него?

Каждый раз, когда мне хочется аппелировать к здравому смыслу я вспоминаю несколько сюжетов. Как в 30х годах повсеместно считался нормальным и здравым экстремальный национализм. Как в середине 20 века, вполне здравой считалась идея о том, что женщины глупее и потому не могут преподавать в университете. Любой здравомыслящий человек не против добавить в бензин немного свинца, это значительно повышает октановое число.

То есть здравый смысл не только у каждого свой, он еще и меняется с течением времени. Тяжело к такой эфемерной вещи аппелировать.
Умные дяди сказали мне, что я идиот, и надо брать Redux.

В мое картине мира, так рассуждают ноубрейн роботы и складывают туда вообще все.

Индустрия говорит — Дэн Абрамов дал нам путь.

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

Когда мне говорят, что в разработке всё уже изобретено, я спрашиваю: «а что, разве у нас не осталось проблем?».

В стандартах\спецификациях и пр. очень много чего есть, но кто их читает? Тыщ-тыщ и в продакшн, классика.

Сам Дэн не раз высказывался о том, что сожалеет о своем творении.
Не встречал такого. Только его статью, что redux не нужен, если нет определенных проблем в проекте. Но там как-то двусмысленно написано.
Очень прошу, скиньте ссылки на эти высказывания!!! Это же какой аргумент убедительный, что автор сам не рекомендует свое творение.

Цель любого искусства изобретение велосипеда. Музыка, живопись. Но любой процесс изучения, сначала идет из повторения, взять тоже Shuhari. Смысл прост, сначала повторяй, потом изобретай. Наличие качественных велосипедов признак мастерства. И на оборот, кто не изобретает велосипеды, тот никогда мастером не станет.

Вы же все понимаете да, что редакс был ответом на адский React.Context API? Я им пользовался, каждый раз с содроганием.


Redux был хоть и в другой парадигме, но проще. Три года уже нет старого Context API и появился новый от которого не хочется плакать. Я конечно навязал своих велосипедов, чтобы было удобнее подключаться к провайдеру из дочерних компонентов (и вдохновлялся Redux коннекторами), но и без этого он вполне работает. Вместо диспатчей и свитчей, обычный стейт компонента и обычнейшие функции внутри компонента которые меняют его стейт. К стейту и функциям можно обращаться из дочерних компонентов, читать и изменять. Всё это без дополнительных библиотек. Бонусом — контексты вложенные в контексты (так например модальное окно может знать, что открыто из другого модального окна), и множественные контексты на одном уровне (например каждая позиция в списке товаров может обладать своим контекстом).


Я понимаю, что при должном уровне упорства этого можно добиться и на Redux, но зачем когда всё из коробки работает?


P. S. Автор спасибо за пост. По себе знаю, что написать свою реализацию под конкретные нужды и макеты часто бывает быстрее, чем разобраться как натянуть чужую под свои чуть отличающиеся задачи. Мир будто треснул на две половины. В одной инженеры эксплуататоры, в другой инженеры изобретатели. Им друг друга не понять, но и без друг друга они не могут. Но вот писать про свои велосипеды я немного побаиваюсь, эксплуататоров больше, а я не Дэн Абрамов и справок всяких не имею

Вы же все понимаете да, что редакс был ответом на адский React.Context API? Я им пользовался, каждый раз с содроганием.
Скорее на адский flux (я про их библиотеку, а не сам подход). Даже reflux был бы лучшим решением между flux, reflux, redux, при введение и соблюдение строгих более-менее грамотных правил в архитектуре, чего большинство не делают или не могут сделать.
Автор почему-то считает, что если он написал свой велосипед (пускай он даже в 2 раза лучше Redux), то это какая-то полезная бизнесу вещь. Этот велосипед надо будет презентовать команде. Которая выскажет замечания. Которые надо будет учесть. Потом надо выкинуть существующее решение. Потом всобачить новое. Потом оно обязательно пару раз свалится в тестах, и ещё пару раз в продакшене. Потом надо будет учить ему каждого новичка. Не иметь возможности задать вопрос или найти ответ на стековерфлов. Не найти подходящего по стеку программиста на рынке. Расширить, чтобы получить вот эту фичу и ещё вот эту фичу, и такое вот… ой, у нас получился тот же Redux. Как же так вышло?
Мда, ясно понятно, лучше каждый день терпеть и жрать гумно когда пишешь очередной говнокод Redux'овский да?
Как насчет того, чтобы поднять голову вверх и посмотреть по сторонам? Например Vue и Svelte значительно удобнее и лучше голого react или react + redux.
Так же посмотрите на React + MobX, вот это шикарнейшая связка, React чисто View, а слой отвечающий за состояние(как локального компонента, так и глобальное) и бизнес логику это уже MobX.
Например Vue и Svelte значительно удобнее и лучше


Svelte ещё сыроват, и нежелание тащить его в продакшен вполне понятно.

Vue — тут, думаю, всё упирается в:

  1. рынок труда. React / Redux спеца найти хоть и тяжело, но, всё же, легче, чем умеюшего во Vue.
  2. возможно, меньший выбор сторонних компонентов под Vue

Не ищите спеца под технологию. Ищите технологию под спеца. Да хороший спец вам и сам её найдёт. И поменяет на новую, когда текущая совсем устареет. А нанятый под технологию спец так и будет вариться в своём технологическом пузыре.

Если нужен второй спец, а есть уже один со своей технологией то как искать?

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

рынок труда. React / Redux спеца найти хоть и тяжело, но, всё же, легче, чем умеюшего во Vue.

Рынок реально кишит адским говнокодом redux'овским или щас модно у некоторых «специалистов» просто на голом реакте писать, это плюс/минус такое же говно получается.
И рынок кишит такими же «спецами» которые все это пишут.
Поэтому найти реального специалиста, а не «специалиста» крайне тяжело т.к. их очень мало, так и в Vue мало именно специалистов, а не «специалистов».
Но по факту если ты умеешь реакт, то ты так же умеешь Vue и наоборот, особенно если оба использовать в связке с MobX, меняется только шаблонизатор по сути, и для тебя просто различие в шаблонизаторах. Мне например JSX больше нравится, но если надо будет писать на Vue, то тоже без проблем.
возможно, меньший выбор сторонних компонентов под Vue

И слава яйцам, когда я вижу проекты в которых просто гигантские package.json'ы меня аж блевать тянет. Потом выяснять баги в сторонних компонентах и написание костылей вокруг них, если тебе нужно шаг влево или вправо, то это так себе удовольствие. Это опять же говорит об уровне нынешних «специалистов» которые весь этот зоопарк используют.

Вещь бизнесу, скорее всего полезная — какие-то задачи решают.

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

Прошла эра Разработчиков, пришло время Прикручивателей. Как хорошо, что есть ещё люди, которые Разрабатывают несмотря на все насмешки и осуждения. Именно эти люди создают прогресс и двигаются вперед. Остальные просто Прикручивают, называя себя Разработчиками.
Так это не только в разработке так. Посмотрите на потребительскую электронику — большинство схемотехнических решений — особенно, в массовом сегменте — используют какие-то стандартные чипы и их обвязку. Потому, что разрабатывать свою схемотехнику — дорого.
Человек из большой корпорации сделал решение для работы с состоянием веб приложения большой корпорации. Редакс решает кучу проблем, которые стоят перед таким приложением, и делает это хорошо.
Дэн тогда еще не был человеком из большой корпорации. Обычный рядовой разработчик. За год до презентации redux закончил институт. Т.е. опыта разработки больших приложений у него было маловато. Да и решение он делал для презентации, без применения его в реальных больших проектах.
Какова вероятность, что такой разработчик таким образом напишет качественное решение для больших проектов? Я считаю, что она в районе нуля.
Так стоп. Я думал, что он сделал именно React-Redux, уже когда был разработчиком в кор команде React. Нет?
Нет, его туда приняли после выступления о redux. Он еще им потом мозг выносил функциональщиной, и в итоге успешно вынес, судя по появлению хуков)
Вот тут он написал о себе — overreacted.io/my-decade-in-review
Насчет института я ошибся видимо. Вроде бы, он не стал его заканчивать.

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


Во втором случае, правда, это не совсем велосипед.


Еще во втором случае надо, чтобы выгода он новых свойств перевесила недостатки от риска, стоимости создания, отсутствия поддержки и так далее.

А вот не может ли кто-нибудь мне, человеку далекому от веба, объяснить зачем нужны фреймворки управления состоянием и желательно дать концептуальный анализ почему они нужны в вебе и не нужны на десктопе, или менее распространены (например в каком-нибудь WPF).


С моей точки зрения вот это вот практически полностью не очень хорошо спроектированный бойлерплейт:


const LoginComponent = (state = initialState, action) => {
    switch (action.type) {

      // This reducer handles any action with type "LOGIN"
      case "LOGIN":
          return state.map(user => {
              if (user.username !== action.username) {
                  return user;
              }

              if (user.password == action.password) {
                  return {
                      ...user,
                      login_status: "LOGGED IN"
                  }
              }
          });
default:
          return state;
      } 
};

И в высокоуровневом коде такое не желательно — хотелось бы как-то связать View с моделью, но при этом не думать об управлении состоянием, причем, в терминах текстовых констант. Типа как в WPF + MVVM.

Штука в том, что в WPF мы не играем в иммутабельность, и работа с состоянием у нас происходит или в модели, или в сервисах. И в отличие от контекста веб приложения на десктопах нет одной важной проблемы — нам не нужно расшаривать состояние между двумя вкладками одного ии того же приложения. Поэтому мы просто говорим — вот это мы храним в оперативке, а вот это вот мы храним на диске. Т.е. у нас такой проблемы просто нет
нам не нужно расшаривать состояние между двумя вкладками одного ии того же приложения.

Я бы уточнил — нужно, но мы обычно это делаем внутри процесса, а не по сети.


Ага, так понятно. А нельзя было как-то более удобно это сделать без всех этих текстовых констант и кейзов? Чтобы оно сраружи выглядело как 2 way binding а внутри была бы вся эта иммутабельность и прочее. Свитчи под капотом, редюсеры знают только про свою часть состояния и так далее.


Или я чего-то не понимаю?

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

А вот персистентность нужна для дешевого перемещения между состояниями. Оправданно ли это — нет, для подавляющего большинства приложений. Но это мое мнение, и я не фронтендер, так что хз

Есть разные архитектуры десктоп приложений например чистый десктоп как текстовый редактор, клиент-серверный десктоп который общается с сервером по API или реже по протоколам удаленного доступа (RMI, CORBA), есть легкий клиент который только рисует интерфейс и воспринимает ввод с клавиатуры и мыши. Все эти приложения имеют под в своем составе модель как правило. Но да, часто не имеют для модели специального фреймверка. Впрочем как и многие веб-приложения.


Необходимость в специальном фреймворке для веб-приложения объективно возникает как мне кажется из проблемы что веб-браузер не разрабатывался для работы приложений а для просмотра документов, поэтому mvc имеет очень запутанную реализацию и наличие некоторого продуманного каркаса позволяет работать более эффективно. К этому добавляется возможность пользоватеем в любой момент перегрузить приожение в любой точке, отстутствие надежного локального хранилища и необходимость в синхронизации данных с сервером в обе стороны. По поводу конкретно redux — да все выглядит весьма усложненно, хотя есть вариант использования redux https://github.com/erikras/ducks-modular-redux в котором все немного проще. Это не другая библиотека а описание того как можно использовать redux с меньшим количеством кода.


Есть еще одна хорошая библиотека по этой теме — effector. Не смотря на то что она разрабатывается недавно с 2018 гда см. https://github.com/zerobias/effector/graphs/contributors — это ниразу не велосипед. Покрывает на 100% функционал redux и mobx и это только часть того что может effector.

По сути фреймворки (скорее библиотеки) управления состоянием — это фреймворки для разработки Model/ViewModel и на декстопе их аналоги вполне есть.


Вот, например, qt: https://doc.qt.io/qt-5/model-view-programming.html


Signals from the model inform the view about changes to the data held by the data source.
Signals from the view provide information about the user's interaction with the items being displayed.
Семь бед — один ответ:
Костыль и велосипед!
Семь бед — один ответ:
Вставь костыль, изобрети велосипед!
©
Я так написал когда-то аналог какой-то монструозной библиотеки для работы с облаками, поддерживающей Gdrive, Dropbox и Яндекс.Диск на дефолтном HTTPUrlConnection для Java, который занимает в итоге… 3 листа A4 (!), хотя другие аналогичные библиотеки весят с операционку.
Хорошо, что создатель вашего любимого инструмента не слушал ослов, когда изобретал велосипед

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


Представьте себе группу разработчиков, которая замахнулась на продукт. Их ожидает два-три года увлекательной жизни с рисованием схем на стирабельных досках, кофе-брейков и прочих внешних признаков творения продукта. При этом разрабатывается по сути велосипед под видом продукта и начинает использоваться в нескольких внутренних проектах. Но рано или поздно наступает момент когда разработчики сливаются и это все оказывается на поддержке у людей которые ничего не знают об этом продукте-велосипеде. И тут как всегда "внезапно" выясняется, что
1) Нет ни строчки документации по продукту-велоспеду
2) В разных проектах заюзаны разные несовместимые версии продукта-велосипеда, а в репе продукта находится только последняя из них
3) Много багов
4) Проблемы с производительностью
В одном из случаев, с котрым я имел дело, разработчики планировали завоевать мир и рубить бабло по полной, поэтому репы размещали в своих личных репозитариях на github под лицензией имени себя, а один из разработчиков или от обиды на работодателя или от стыда за свой код — просто закрыл или удалил репу с исходным кодом. Когда это выяснилось, пришлось восстанавливать ее из кода на продакшин сервере.


Если разобраться объективно, мог ли у них получиться продукт а не велосипед. Может быть у них был шанс? Я бы ответил что нет, не мог. По причинам, что задачи которые они ставили имели более высокую трудоемкость, чем мог позволить их коллектив. Такие вещи как документирование, тестирование, версионирование, доставка изначально не были продуманы и внедрены, и значит не могли быть внедрены никогда. Это как бы объективно. Кроме того такие моменты которые конечно уже можно оспорить как отсутствие опыта, критического отбора решений но это уже лирика.


Я это к тому говорю, что продукт он изначально имеет многое из того что отичает его от велосипеда.

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


Вобщем я полностью согласен и поддерживаю мысли автора в этой статье!

Ну вообще, если проект работает и легко модифицируется, можно смело посылать всех нахер
Феномен называется «ведро с крабами». Люди сами не умеют изобретать, вот и пытаются отговорить других, выдумывая миллион причин, почему это «не нужно» или даже «вредно».

image

Полностью согласен с автором. Я когда начал писать свою ORM-либу на плюсах мне то же самое говорили https://github.com/fnc12/sqlite_orm. А сейчас она на втором месте по кол-ву звезд среди ORM для SQLite3 на плюсах на гитхабе

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