Комментарии 104
Смотрит разработчик на код и спрашивает — "а кааак это поддерживать?".
Тонны редакс-быдлокода, написанные в режиме "главное завалить а там ногами запинаем" мы не спрашиваем как поддерживать. А небольшой, но свой стейт-менеджмент в 500 строк кода суммарно — всё, проблема проблем! Мы не знаем что делать кроме как рыдать "спаситипамагити мамочка тут велосипед!", "да, мы видим его код, мы знаем буквы которыми он написан, мы знаем язык на котором он написан но ОООО УЖАС КАК ЖЕ ЭТО ПОДДЕРЖИВАТЬ?!".
И действительно. Неподвластная человеческому уму задача.
P.S: а вы часто смотрите в код пакетов, которые вы используете? А количество открытых issues? А когда был последний коммит — тоже проверяете? А документацию на сайте с API сопоставляете (вдруг там не всё описано)? А как вы будете поддерживать своё приложение если завтра автора вашего, конечно же, не-велосипедного пакета из npm собьёт автобус вы часто спрашиваете?
У меня есть история на эту тему. Прикручивал я mobx к angular. Взял mobx-angular, который использовал недокументированное апи, чтобы подцепиться к ангуляру. Ни у кого вопросов не возникло, ведь это сторонний пакет.
Но решил я его улучшить, добавив поддержку SuspenseAPI, поэтому форкнул, чуть упростил и добавил эту фичу. Кода там с гулькин нос. То теперь это (о ужас!) использование недокументированного апи в нашем репозитории. В результате этот пулреквест пришлось откатить и написать кучу бойлерплейта из-за отсутствия SuspenseAPI.
P.S: а вы часто смотрите в код пакетов, которые вы используете? А количество открытых issues? А когда был последний коммит — тоже проверяете? А документацию на сайте с API сопоставляете (вдруг там не всё описано)? А как вы будете поддерживать своё приложение если завтра автора вашего, конечно же, не-велосипедного пакета из npm собьёт автобус вы часто спрашиваете?
Если за систему баксуют как положено или проект мой, то конечно все это делается и все репы клонируются к себе, а если оплата далека от ожидаемой, то мне пофигу какой там пакет и что он там, забью костыль и потом соскочу при первой возможности, это обще принятая практика, в большинстве случаев по коду видно, когда кончилось бабло или что то случилось в менеджменте.
На самом деле, довольно просто: если компания энтерпрайз, может быть текучка, то, конечно, любой говнокод на редаксе лучше, чем на велосипеде. Learning Curve, там.
Но на практике, есть разработчики, которые не могут разобраться даже в Redux. Для них middleware — это магия высшего порядка, код, написанный сеньерами для лидов.
Dependency Injection? Conversion of control? Вы што?
Поэтому да, если уж хреновый код написан на популярной библиотеке (а этого, к сожалению, не избежать), разгребать его будет проще, чем хреновый код на неизвестном велосипеде.
Из примера
Есть Андроид с его фрагментами и идиостким апи перехода:
взять активити, достать фрагмент менеджера, создать фрагмент, сказать фрагмент менеджеру возьми этот фрегмент пихни во вью, пихни в стек, дай ему тег, если надо.
А если в верстке есть косяк или дизайн что то требует (показать тул бар, скрыть таббар) при переходе в фрагменты, то нужно дотягиваться до активити при переходе. Кто с этим работал, тот видел весь этот говнокод смены фрагментов в чужих проектах (вызов этого апи из адаптеров списков, например) :)
Жуть.
Есть библиотеки состояний с развитым апи, там текста инструкций больше чем надо кода.
Определить интерфейс сможет и джун: Вперед, назад, назад в корень, заменить.
Навесить пару паттернов состояний (forward/bacward):
И вот за час рождается библа, которая с 2016 (создана 2016‑11‑24) года поменяла поменяла только положение переменных в вызове какого то метода.
Т.е. на создание такого велосипеда ушло меньше времени чем на изучение и внедрение существующих и данная либа ушла проектов в 20-30.
А вот вся эта мишура с развитым апи, гибкостью и другими штуками очень часто не нужна.
— Так, я хочу шаг назад… Ой, флаг is_fetching откатился, ладно, хочу ещё назад, ой флаг is_fetching у другого объекта стора откатился, да что ты будешь делать… Ведь это же такая фича просто жизненно необходимая, а не работает на практике, какой кошмар.
Time Travel через механизм Undo/Redo сделать легко. А вот сделать механизм Undo/Redo через Redux — сложно.
Если в вашем конфетном мире существует только React 16+, то мои вам поздравления.
А это как стартапы — надо ли создавать свою компанию? Да вы что, это же дикий геморрой и 95% шанс прогореть и потратить время просто так, просто работать в корпорации куда надежнее и безопаснее. Но да, все существующие компании когда-то были стартапами…
Та же история с велосипедами. 95% или 99% оказываются субстанцией, но иногда что-то взлетает.
Более того, та же примерно история с собеседованиями. 95% кандидатов не проходят интервью — в принципе, логично было бы их и не проводить с таким процентом. Но другого варианта нет.
Инструмент обычно берётся под задачу, и только время показывает насколько верным был выбор. Обычно на старте решения какой-то проблемы не видны все подводные камни. Так что я предпочитаю брать что-то готовое, что должно подходить и допиливать уже его. Если это делать трудно, то скорее всего я что-то делаю не так, и есть повод пересмотреть выбор. Имхо, только на этом шаге имеет смысл делать свой велосипед — когда известно что и каким образом надо делать.
Если вы действительно считаете, что основаная задача разработки — рефакторить легаси (а как еще можно понять фразу «Бизнес не понимает, почемы мы должны две недели не делать фичи, а приводить в порядок легаси»?) — то это довольно странная позиция.
Ну и про процессы странное предложение в тексте. Я против бюрократии, но процессы точно нужны, если разработчиков > 1.
Бизнес может банально упереться рогом и не дать достаточно времени на нормальную реализацию очередной фичи, которая резко стала нужна ещё вчера. Бизнес может со временем изменить или добавить хотелки так, что некоторые вещи имеет смысл отрефакторить прямо сейчас дабы потом не наращивать тонны плохого и/или однотипного кода.
Вот честное слово, иногда читаешь и ловишь себя на мысли, что все вокруг знают хотелки раньше самого бизнеса, отчего сразу проектируют и пишут код идеально и на годы вперёд. Не имеют никакого технического долга, не делают никакого рефакторинга или адаптации узких мест под возросшие нагрузки. Как-то это всё, к сожалению, расходится с наблюдаемой мной реальностью чуть менее чем всегда.
Ничего не напоминает? А я такое вижу чаще, чем «бизнес, который требует вчера».
Бизнес платит за то, что считает нужным, а разработчик пишет код так, как считает нужным. Если их представления о прекрасном не совпадают, то бизнес ищёт себе другого разработчика или разработчик ищет себе другой бизнес. Только и всего. Не нужно пытаться разнашивать ботинки, меньше нужного на два-три размера.
А теперь разработчик приходит и говорит биизнесу: следующие полмесяца-месяц будешь платить за то, что я хочу делать, а не за то, что тебе надо. Нормально? Думаю нет.
Честно — я только за чистый и аккуратный код, но мне не нравится, когда это предподносят как «бизнесу всё-равно за что платить, поэтому мы тут сами решим что нам делать».
Разработчик может банально упереться рогом и делать элементарную вещь месяцами, которая резко стала нужна ещё вчера. Разработчики могут закладывать в сроки то, что не имеет смысла и не понадобится многие десятилетия.
Это абсурд. Бизнес и только бизнес решает какие задачи берутся в спринт, а какие будут в беклоге лежать месяцы и годы. Что там разработчик может решать в этом смысле?
То есть если бизнес игнорит задачи по рефакторингу, то он сам и гробит свой проект.
Если же он форсит писать быстрее и не дает разработчику достаточно времени на нормальную реализацию очередной фичи — происходит тоже самое, гробится проект, превращаясь в неподдерживаемое нечто.
превращаясь в неподдерживаемое нечто
Верно и потом уже делается версия 2.0 с полного нуля уже основательно и с головой. Ибо ни один уважающий себя разраб не будет в говне ковыряться. Я уже много проектов делал «2.0» с полного нуля, т.к. то, что было, было не пригодно к существованию от слова совсем. Но мне то что, мне по кайфу с нуля писать.
По нынешним временам всё чаще встречается переделывание не с полного ноля сразу, а поэтапно через вынос в сервисы/микросервисы.
P.S. фичу проектом называть не хочу. Фичу можно выкинуть и переписать.
Так вот для средне-больших и больше проектов — не верю что переписать — решает проблемы заказчика. Заказчик помнит необходимых требований около 30% от реализованных(любил читать код при рефакторинге), если не документировал постоянно, особенно когда куча разных фич и их комбинаций. Так и будете по кругу переписывать, или рефакторить(уже свой код) по мере «вспоминания требований».
Хотя стойте, первопричина в отсутствии времени(а значит и лишних денег тоже).., а значит вы уже ускакали после заказа. Заказчику, конечно, стыдно послать всех и за всё вдогонку, но знайте это.
Если же денег хватает, то вот и аргумент за своевременный рефакторинг, и сказка, что скупой(заказчик) платит уже трижды.
Бизнесу с таким подходом — удачи, она ему понадобится.
А если разработчики пишут такой код, что его надо через неделю переписывать — повод задуматься, верно?
Почему через неделю, а не на следующий день? На "следующий день" было бы больше поводов задуматься, верно?
Но, к сожалению, в большинстве случаев велосипеды изобретают из тщеславия — очень хочется сделать свой знаменитый проект — или из лени и неграмотности, когда не могут или не хотят разобраться с уже существующими решениями. И вот это скверно.
Проблема людей в том, что те, кому нравится ваш модуль, молча оценят и будут использовать его в своих проектах, а те 10% людей, кому он не понравится тут же дадут знать вам в комментариях. А поскольку большинство комментариев пишутся теми, кому что-то не понравилось, создается общее негативное восприятие того, что ваш проект никому не нравится.
Тебе блин не нужен персистентный чейн всех слайсов стейта приложения
И вроде всё понятно, но осадочек остался
Люблю делать велосипеды в своих pet-проектах. Если сталкиваюсь с какими-то фундаментальными проблемами — разбираюсь, как сделано "под капотом" в других решениях. В итоге получаю кучу опыта и понимание возможных подходов.
Например, когда я осваивал 3д графику, написал свой код для векторов, матриц и кватернионов. В процессе собрал все грабли и досконально разобрался. После этого я могу взять любую библиотеку, использовать её на 100% и при необходимости дописать недостающую функциональность.
Вместо этого некоторые люди, не разобравшись в происходящем, устраивают карго-культ больших серьёзных решений и начинают забивать гвозди микроскопом.
— Карго культ, говорите Вы? — хехе, смотрит прог на Вас с прищуром ).
Когда вам говорят о велосипеде, то подразумевают не его конструкцию, а количество вложенного в него труда, потому как никто не хочет платить свои деньги за велосипед, который нужно ремонтировать либо долго настраивать сразу после покупки.
Ведь советское время, когда любой новый агрегат сразу приходилось донастраивать, давно уже закончилось. И большинство людей об этом совершенно не жалеет.
Автора прекрасно понимаю, так как сам сделал похожий “велосипед” (только под Ангуляр). И статью про его принципы написал. И хотел даже сделать её перевод на Хабре, но пока не решился, поскольку опасаюсь описанной автором реакции.
Думаю, что причина подобного отношения — это не то, что кто-то создал “велосипед”, а то, что этот кто-то не обладает достаточным авторитетом в глазах остальных разработчиков. Если бы эту библиотеку сделал Гугл, Фейсбук или, на худой конец, Яндекс, то её возможно критиковали бы, но никто бы не назвал её “велосипедом”.
С другой стороны, принцип “авторитета” отнюдь не плох, так как попросту позволяет экономить время, не тратя его на подробный анализ тысяч схожих “поделок”. Возможно, среди этих “поделок” на самом деле есть “брильянты”, тщательно обработанные их авторами, но их мало и шанс найти что-то выдающееся невелик, поэтому и берут известное решение так как оно в 99% случаев не будет самым худшим, а в 99% случаев это и достаточно.
Как говорится, haters gonna hate, но адекватные люди, увидев понятное рациональное обоснование, вряд ли станут критиковать пусть и нишевое, но решение, нацеленное на конкретные и объективно существующие недостатки.
У меня так велосипедный полу-пет проект на работе вырос в огромный проект) живёт себе и растет дальше, ещё разрабов нанимают. С тех пор никто мне не говорит, что это велосипед)
Тут было бы уместно спросить чем велосипед отличается от продукта. Вроде бы тот же программный код, разработчиков у продукта может быть даже меньше, чем у велосипеда. То есть те кто не хотят велосипеда — чего они не хотят? На мой взгляд не хотят отсутствия документации, отсутствия версионирования и минимальной обратной совместимости, отсутствия поддержки, отсутствия вменяемой загрузки через регистр (например через npm, pip, composer), отсутствтвия нужных для разработки API и должного тестирования, проблем с производительностью которые "внезапно" вылазят на проде, подводных камней на которые наскакиваешь когда половина проекта уже сделана и спрыгнуть с "велосипеда" уже нельзя. А в остальном — все хорошо.
Пример не корректный. Как в случае с xml так и в случае json авторы занимались разработкой стандарта, фактически документации. Корректным примером было бы если бы некий гипотетический автор реализовал метод xmlserialize и xmlserialize для объектов и включил это в проект без описания протокола сериализации и десериализации. Это был бы классичекий велосипед. И от был бы вреден так как никто не понимал бы как работает "эта магия'. И как поддержкивать этот проект.
Велосипедостроители бывают разные и причины у них разные
- Не разобрался как это работает и решил что может лучше. Результат как правило хуже, но автор отказывается в это верить.
- Разобрался как это работает, но не разобрался почему и для чего (не знает домена(во)) в которых используется инструмент, не знает даже своего домена. Результат — велосипед, который вроде как хорош, но на практике куча геморроя.
- Прошёл этапы 1 и 2, стал экспертом в области и запилил свой велосипед, который оказался лучше существующих.
Я не знаю, что за инструмент вы сделали, знаю только, что редакс это редкостное г… но, в котором есть здравые идеи. Ваша мотивация мне понятна. К сожалению русскоязычное коммьюнити очень злое. Я бы сразу писал все на английском и рассказывал об инструменте на HN и Reddit. Так будет больше шансов получить позитив. Только там другая проблема — вам скажут «все круто, давно хотел такую штуку, вот бы ещё там было X и Y» Вы можете броситься ее делать, а вам это написали просто из вежливости.
Мораль — если вы на этапе 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 логично вытекали из потребностей времени. Крокфорд не гений, идеи и так витали в воздухе, он оказался авторитетом, который озвучил их и получил себе славу первооткрывателя. Уверен, что менее популярные люди высказывали аналогичные идеи чуть раньше, просто им не повезло.
Времена ajax пришли немного позже. По поводу гибкости xml у него есть один недостаток. В нем сложно хранить массивы. При этом не различаются массива состоящие из одного элемента и объект если нет схемы документа. Кроме того каждый элемент массива должен иметь имя что также приводит к избыточности. Например
House
Appartments
Appartment
1
Appartment
2
В этом смысле json оказался даже гибче и в некотором смысле мощнее xml
противоположный подход это «кодинг по индусски» — прицепить сотни мегабайт .jar-ов и прочих сторонних библиотек чтобы 50 строчек из стековерфлоу заработали, когда можно было сделать нормально.
Во всём нужен здравый смысл — без него никуда.
То есть здравый смысл не только у каждого свой, он еще и меняется с течением времени. Тяжело к такой эфемерной вещи аппелировать.
Умные дяди сказали мне, что я идиот, и надо брать Redux.
В мое картине мира, так рассуждают ноубрейн роботы и складывают туда вообще все.
Индустрия говорит — Дэн Абрамов дал нам путь.
Сам Дэн не раз высказывался о том, что сожалеет о своем творении.
Если разобраться, то не особо то оно и нужно это хранение, а уж если еще и головой подумать то стейт менеджер нужен еще меньше.
Когда мне говорят, что в разработке всё уже изобретено, я спрашиваю: «а что, разве у нас не осталось проблем?».
В стандартах\спецификациях и пр. очень много чего есть, но кто их читает? Тыщ-тыщ и в продакшн, классика.
Сам Дэн не раз высказывался о том, что сожалеет о своем творении.Не встречал такого. Только его статью, что redux не нужен, если нет определенных проблем в проекте. Но там как-то двусмысленно написано.
Очень прошу, скиньте ссылки на эти высказывания!!! Это же какой аргумент убедительный, что автор сам не рекомендует свое творение.
Цель любого искусства изобретение велосипеда. Музыка, живопись. Но любой процесс изучения, сначала идет из повторения, взять тоже Shuhari. Смысл прост, сначала повторяй, потом изобретай. Наличие качественных велосипедов признак мастерства. И на оборот, кто не изобретает велосипеды, тот никогда мастером не станет.
Вы же все понимаете да, что редакс был ответом на адский React.Context API? Я им пользовался, каждый раз с содроганием.
Redux был хоть и в другой парадигме, но проще. Три года уже нет старого Context API и появился новый от которого не хочется плакать. Я конечно навязал своих велосипедов, чтобы было удобнее подключаться к провайдеру из дочерних компонентов (и вдохновлялся Redux коннекторами), но и без этого он вполне работает. Вместо диспатчей и свитчей, обычный стейт компонента и обычнейшие функции внутри компонента которые меняют его стейт. К стейту и функциям можно обращаться из дочерних компонентов, читать и изменять. Всё это без дополнительных библиотек. Бонусом — контексты вложенные в контексты (так например модальное окно может знать, что открыто из другого модального окна), и множественные контексты на одном уровне (например каждая позиция в списке товаров может обладать своим контекстом).
Я понимаю, что при должном уровне упорства этого можно добиться и на Redux, но зачем когда всё из коробки работает?
P. S. Автор спасибо за пост. По себе знаю, что написать свою реализацию под конкретные нужды и макеты часто бывает быстрее, чем разобраться как натянуть чужую под свои чуть отличающиеся задачи. Мир будто треснул на две половины. В одной инженеры эксплуататоры, в другой инженеры изобретатели. Им друг друга не понять, но и без друг друга они не могут. Но вот писать про свои велосипеды я немного побаиваюсь, эксплуататоров больше, а я не Дэн Абрамов и справок всяких не имею
Вы же все понимаете да, что редакс был ответом на адский React.Context API? Я им пользовался, каждый раз с содроганием.Скорее на адский flux (я про их библиотеку, а не сам подход). Даже reflux был бы лучшим решением между flux, reflux, redux, при введение и соблюдение строгих более-менее грамотных правил в архитектуре, чего большинство не делают или не могут сделать.
Как насчет того, чтобы поднять голову вверх и посмотреть по сторонам? Например Vue и Svelte значительно удобнее и лучше голого react или react + redux.
Так же посмотрите на React + MobX, вот это шикарнейшая связка, React чисто View, а слой отвечающий за состояние(как локального компонента, так и глобальное) и бизнес логику это уже MobX.
Например Vue и Svelte значительно удобнее и лучше
Svelte ещё сыроват, и нежелание тащить его в продакшен вполне понятно.
Vue — тут, думаю, всё упирается в:
- рынок труда. React / Redux спеца найти хоть и тяжело, но, всё же, легче, чем умеюшего во Vue.
- возможно, меньший выбор сторонних компонентов под Vue
Не ищите спеца под технологию. Ищите технологию под спеца. Да хороший спец вам и сам её найдёт. И поменяет на новую, когда текущая совсем устареет. А нанятый под технологию спец так и будет вариться в своём технологическом пузыре.
рынок труда. React / Redux спеца найти хоть и тяжело, но, всё же, легче, чем умеюшего во Vue.
Рынок реально кишит адским говнокодом redux'овским или щас модно у некоторых «специалистов» просто на голом реакте писать, это плюс/минус такое же говно получается.
И рынок кишит такими же «спецами» которые все это пишут.
Поэтому найти реального специалиста, а не «специалиста» крайне тяжело т.к. их очень мало, так и в Vue мало именно специалистов, а не «специалистов».
Но по факту если ты умеешь реакт, то ты так же умеешь Vue и наоборот, особенно если оба использовать в связке с MobX, меняется только шаблонизатор по сути, и для тебя просто различие в шаблонизаторах. Мне например JSX больше нравится, но если надо будет писать на Vue, то тоже без проблем.
возможно, меньший выбор сторонних компонентов под Vue
И слава яйцам, когда я вижу проекты в которых просто гигантские package.json'ы меня аж блевать тянет. Потом выяснять баги в сторонних компонентах и написание костылей вокруг них, если тебе нужно шаг влево или вправо, то это так себе удовольствие. Это опять же говорит об уровне нынешних «специалистов» которые весь этот зоопарк используют.
Вещь бизнесу, скорее всего полезная — какие-то задачи решают.
Человек из большой корпорации сделал решение для работы с состоянием веб приложения большой корпорации. Редакс решает кучу проблем, которые стоят перед таким приложением, и делает это хорошо.Дэн тогда еще не был человеком из большой корпорации. Обычный рядовой разработчик. За год до презентации 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.
нам не нужно расшаривать состояние между двумя вкладками одного ии того же приложения.
Я бы уточнил — нужно, но мы обычно это делаем внутри процесса, а не по сети.
Ага, так понятно. А нельзя было как-то более удобно это сделать без всех этих текстовых констант и кейзов? Чтобы оно сраружи выглядело как 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.
Семь бед — один ответ:©
Костыль и велосипед!
Семь бед — один ответ:
Вставь костыль, изобрети велосипед!
Хорошо, что создатель вашего любимого инструмента не слушал ослов, когда изобретал велосипед
Не обратил внимание на заголовок статьи. Возможно он изначально был другим. Не совсем корректно всех кто не согласен с Вашим мнением априори назвать ослами. Но дело не в этом. На мой взгляд спорное мнение, что все продукты когда-то были велосипедами, а уже потом стали продуктами. Или возможно продуктами Вы и Ваши оппоненты называют немного разные явления и в этом недопонимание. Мне слишком много приходилось иметь дело с чужими велосипедами чтобы сказать что с ними сложно работать. И вот почему.
Представьте себе группу разработчиков, которая замахнулась на продукт. Их ожидает два-три года увлекательной жизни с рисованием схем на стирабельных досках, кофе-брейков и прочих внешних признаков творения продукта. При этом разрабатывается по сути велосипед под видом продукта и начинает использоваться в нескольких внутренних проектах. Но рано или поздно наступает момент когда разработчики сливаются и это все оказывается на поддержке у людей которые ничего не знают об этом продукте-велосипеде. И тут как всегда "внезапно" выясняется, что
1) Нет ни строчки документации по продукту-велоспеду
2) В разных проектах заюзаны разные несовместимые версии продукта-велосипеда, а в репе продукта находится только последняя из них
3) Много багов
4) Проблемы с производительностью
В одном из случаев, с котрым я имел дело, разработчики планировали завоевать мир и рубить бабло по полной, поэтому репы размещали в своих личных репозитариях на github под лицензией имени себя, а один из разработчиков или от обиды на работодателя или от стыда за свой код — просто закрыл или удалил репу с исходным кодом. Когда это выяснилось, пришлось восстанавливать ее из кода на продакшин сервере.
Если разобраться объективно, мог ли у них получиться продукт а не велосипед. Может быть у них был шанс? Я бы ответил что нет, не мог. По причинам, что задачи которые они ставили имели более высокую трудоемкость, чем мог позволить их коллектив. Такие вещи как документирование, тестирование, версионирование, доставка изначально не были продуманы и внедрены, и значит не могли быть внедрены никогда. Это как бы объективно. Кроме того такие моменты которые конечно уже можно оспорить как отсутствие опыта, критического отбора решений но это уже лирика.
Я это к тому говорю, что продукт он изначально имеет многое из того что отичает его от велосипеда.
Просто хочу написать, что ты, парень, не один такой :) я тут в свободное от работы время пишу чат-бот с использованием инструментов, которые написал самостоятельно и которые являются велосипедами, потому что на рынке уже полно подобных вещей. И я не могу открыть код своего чат бота только потому, что пацаны скажут "Велосипед же используешь, сделал бы лучше на <всем известная библиотека>". Даже больше того, я переживаю и не могу просто так взять и пригласить в проект нового разработчика, потому что он с порога скажет мне, что в проекте одни велосипеды и он не будет с этим работать. Поэтому я и дальше буду изобретать велосипеды, чтобы удобства этих велосипедов хватило поддерживать и развивать этот продукт без потерей для бизнеса.
Вобщем я полностью согласен и поддерживаю мысли автора в этой статье!
Полностью согласен с автором. Я когда начал писать свою ORM-либу на плюсах мне то же самое говорили https://github.com/fnc12/sqlite_orm. А сейчас она на втором месте по кол-ву звезд среди ORM для SQLite3 на плюсах на гитхабе
Построение велосипедов -- это прежде всего лучший способ самообучения и развития в профессии. Но в работе тоже помогает.
Хорошо, что создатель вашего любимого инструмента не слушал ослов, когда изобретал велосипед