Comments 333
Вот я не совсем соглашусь с Вами, а соглашусь с автором… у меня не большая команда… и технологию я оцениваю так… если через более пол-года возвращаемя к коду расшририть функциональность… поправить баг… то для примера java(erp система)… разработан "целый космос " и всегда к коду возвращаться легко… легко дополнить и нет побочных эффектов.возможно из-за принципа концепции ленивой подгрузки кода… А вот в реакте небольшие проектики.(не то что у автора статьи) и вернуться к коду через время(React+Redux) или что-то дополнить… Это боль… я сменил стек .
И что сейчас? Ангуляр?
Вы знаете я как предприниматель в ИТ… рассуждаю просто(Мой взглаяд может не подходить для крупного бизнеса)… с точки зрения уменшения ресурса(технического, административного, по сопровождению)… Мои проекты связаны с базами данных(автоматизацией бизнеса)… для малого и среднего.
И в зависимости от ситуации или 1.Oracle Apex(Это быстрая среда для разработки бизнес приложений… мне кажеться быстрее нельзя можно только повтороить).
2.Или(если проект будет иметь много отраслевых подрешений) PHP+HTML контролы на jQuery
2 Со временем всё сложнее будет находить специалистов, готовых с этим работать. Особенно вдолгую.
Oracle Apex(Это быстрая среда для разработки бизнес приложений… мне кажеться быстрее нельзя можно только повтороить)
Быстрая среда для разработки бизнес-приложений — 1С: Предприятие. Не думаю, что в Oracle Apex можно быстрее что-то сделать.
Именно почему я не знаю...(тут же была ремарка для меня)… это по моему опыту… есть проекты на react(Это POS кассы на планшете… магазин ресторан), ЕГАИС Проверка марок(тоже чтоб мобилу использовать… тут React к месту) На java вообще большая кросспоатформенная Desctop ИС.с дублирующими web мордами для некторых отраслевых процессов(vaadin Это java). и oracle apex.Так вот если вдруг(для меня) нужно вернуть и доработать react… Это всегда выход из зоны комфорта… Пока пишешь(React)… держишь в уме "нить" вроде нормально. Решение выпущено работает… вернуться к нему… всегда жалеешь ,-на кой я выбрал React в этом решении… Возможно какая-то эфимерная нечёткая концепция у React… что потом "концы" сложно собрать в кучу".(Сугубо по моему мнению)
У меня только один вопрос — почему технические решения принимает человек, знающий лишь полтора фреймворка?
Чтобы принимать взвешенное решение нужно иметь достаточно широкий кругозор, не ограничивающийся парой наиболее популярных вариантов.
Не пробовал в бою = не знал.
За выбор любого высокоуровневого фреймворка ($mol, ExtJS, SAPUI5, да хоть 1С) его бы только похвалили.
Если учесть все сотни фреймворков которые существуют в JS, а по вашему их надо все попробовать в бою, то надо каждый новый проект писать с использованием нового фреймворка? Или сразу в одном проекте использовать 2-3 чтобы время сэкономить?
Типов фреймворков от силы десяток наберётся. Достаточно ознакомиться с представителем от каждого.
Если у самого не хватает опыта для принятия такого решения — всегда можно нанять того, у кого этот опыт есть для консультации. А не обрекать "большой и долгий проект" на кучу легаси и рефакторинги в первые же пару лет.
Самомнения у таких вот "любителей реакта" много, а совести — нет.
Проблема в архитектуре, которая этими самыми фреймворками форсируется. И их экосистеме, которая не позволяет сесть и поехать, а требует кучу бессмысленных приседаний.
Тут у людей уже через год тыква начала получаться. И чем дальше, тем тыквеннее.
Расскажите про тыкву ребятам из .NET или Java Enterprise которые поддерживают проекты часто больше 7 лет.
Вот реакт как раз ничего особо не форсирует
Ну конечно..
- push семантика.
- отсутствие двустороннего связывания.
- необходимость ручного прокидывания: классов для стилизации, идентификаторов для привязки тестов, контекста для локализации и тп.
- невозможность сделать нормальную инверсию контроля.
- невозможность рефлексии компонента.
- невозможность переноса компонента в другого родителя без его пересоздания.
И это список можно ещё долго продолжать.
Просто перестаньте относиться к реакту как к тому, чем он не является — полноценному фреймворку.
Ок. Реакт навязывает единственную вещь: вью — чистая функция от переданных свойств и, опционально, стэйта и рендерится автоматически при их изменении в терминах JS. Если собираетесь с этим бороться, то это будет больно.
Обязательно, как только перестанут врать про "у нас проект на Реакте", скрывая от руководства, что на самом деле "проект на кривом велосипеде, слепленном из Реакта и ещё 10 библиотек и скрученных синей изолентой". Я много проектов повидал "на Реакте" — везде одни и те же проблемы. И они очевидны были с самого начала.
Начнём с того, что вьюшки в Реакте не являются чистыми, кроме разве что совсем тривиальных. А закончим тем, что больно бывает лишь при отсутствии идемпотентности, которую обеспечивает не чистота, а реактивность.
необходимость ручного прокидывания: классов для стилизации
Но зачем? Стилизация компонентов — ответственность самих компонентов, а возможная вариативность — это часть явного интерфейса компонента, которой в пропсах самое место. Да и то, не факт, что там нужны именно CSS-классы, а не флаги или другие высокоуровневые параметры.
В разных контекстах необходимо менять разные особенности визуализации компонента. Попытка выразить всё многообразие кастомизаций в пропсах выливается в свой недо css. За примерами можете посмотреть любой более-менее матёрый компонент. Фронтенд ходит по кругу, наступая на одни и те же грабли с каждым витком.
В разных контекстах необходимо менять разные особенности визуализации компонента.
Здесь проблематика аналогична модификаторам в BEM: очень тонкая грань между кастомизацией и вообще другим отображением. Во втором случае — это разные компоненты, в которых можно легко переиспользовать логику, обернутую в хук.
А просовывание классов ломает саму идею компонентного подхода — оборачивающий код жестко завязывается на низкоуровневую специфику отображения своего дочернего компонента.
За примерами можете посмотреть любой более-менее матёрый компонент.
Матерые компоненты (DevExtreme, к примеру) имеют богатые настройки отображения через параметризацию, хотя и поддерживают передачу css-классов в некоторых местах.
Во втором случае — это разные компоненты, в которых можно легко переиспользовать логику, обернутую в хук.
Это не работает, когда у вас компонент чуть сложнее кнопки. Ну, например, компонент "навигатор по WebDAV" и вам надо в конкретном приложении сделать, чтобы иконки фалов увеличивались при наведении на имя файла. А компонент этот поддерживаете вообще не вы. Сколько итераций потратите на реализацию этой дизайнерской задумки?
Матерые компоненты (DevExtreme, к примеру) имеют богатые настройки отображения через параметризацию
Эти настройки обычно покрывают лишь 60% потребностей проекта. Что делать с остальными 40%? Писать фичереквест и ждать с моря погоды? Форкать, вставлять костыли и поддерживать их при каждом обновлении? Форкать, неделю разбираться как адекватно сделать нужную тебе фичу, после чего ещё месяц бодаться с мейнтейнером, чтобы он принял мерж реквест?
вам надо в конкретном приложении сделать, чтобы иконки фалов увеличивались при наведении на имя файла. А компонент этот поддерживаете вообще не вы.
Предлагается изменить внутреннее поведение компонента. Если так, то логичнее было бы его в самом деле форкнуть и наделить необходимым функционалом, а не патчить результат извне. Не факт, что будет дороже, но 100% — надежнее.
Форкать, вставлять костыли и поддерживать их при каждом обновлении?
Внедряясь во внутреннюю структуру разметки и стилей так же никто не сможет гарантировать, что при следующем обновлении все не поломается.
Примечательно, что на поставленные вопросы вы так и не ответили.
А что если...
… можно построить архитектуру так, чтобы:
- Минимизировалась вероятность поломки при обновлении.
- При поломке падала бы сборка, а не появлялись скрытые баги.
- Изменения хранились бы в репозитории потребителя компонента, а не требовались форки.
- Достаточно было бы пары простых строчек кода, а не головоломные портянки.
на поставленные вопросы вы так и не ответили.
На все поставленные вами вопросы вроде бы ответил прямо или косвенно. Давайте еще раз:
Сколько итераций потратите на реализацию этой дизайнерской задумки?
Тут вы число ждали? Вслепую оценивать объем работ как-то странно.
Что делать с остальными 40%?
Искать более подходящий компонент или форкать имеющийся.
можно построить архитектуру так, чтобы:
Предлагаемый подход с патчингом удовлетворяет лишь крайнему пункту.
Не то чтобы это было плохо в рамках одной ветки комментариев, но к сожалению эта назойливая самореклама стала регулярной.
Я там ещё троих упомянул, если вы не заметили. Любой из них подошёл бы для задач автора лучше Реакта. И даже лучше Ангуляра.
Для корпоративного приложения, для которого даже Реакт — слишком быстро развивающаяся и меняющаяся штука?
Реакт так-то довольно медленно именно развивается, не смотря на частые изменения в апи и, особенно, экосистеме. Тот же $mol за то же время куда более существенно развился (появилось и исчезло квантование, появилась виртуализация, полностью переработана система реактивности, дважды), при этом для прикладного разработчика мало что поменялось. Реакт же тем временем всё никак не допилит фичи, которые были в $mol изначально (Suspense, Dependency Tracking, Context).
Вот вы постоянно пытаетесь пиарить $mol, и я очень даже допускаю что он очень крут как фреймворк. Но вы постоянно это делаете настолько агрессивно, с позиции "вы все дурачки и не лечитесь", что никакого желания даже смотреть в ту сторону не хочется. Советую вам пиаром заниматься не с негативной а с позитивной стороны.
Я уже года 3 как не пиарю $mol, а делюсь идеями, наработками и результатами анализа. Тем не менее:
Но вы постоянно это делаете настолько агрессивно, с позиции "вы все дурачки и не лечитесь", что никакого желания даже смотреть в ту сторону не хочется.
Это довольно дурацкий ход мысли, показывающий иррациональность вашей позиции.
ExtJS для такого вполне зашёл бы, разве нет?
ExtJS для такого вполне зашёл бы, разве нет?
Верно. ExtJS — это свыше 500 классов. Что-то вроди Дельфи для фронтенда.
И ExtJS — платный. Но это как-раз для энтерпрайз проекта.
Короче — ExtJS — это то что как-раз нужно для энтерпрайз проекта — повиснуть на нём и платить и платить и платить (а также ждать когда решат проблему, ждать и ждать) — короче — хотите надолго зависнуть и дорого платить — выбирайте ExtJS.
Единственно ExtJS пользуется менее — 0,5% разработчиков — но свыше 500 классов! — Что вам ещё нужно то? Особенно если вы что-то делаете для внутреннего(!) продукта употребления в банке, к примеру!
Ну я вот один из тех 0.5%, скрывать не буду.
Вы кроме числа классов и платности про него что-то ещё знаете? Например, про огромное количество настроек и надстроек? Или про то, что его формат функциональных таблиц толком никто не повторил с тех пор, и именно из-за таких таблиц проект вообще до сих пор шевелится? Или хотя бы про то, что все 500 или сколько их там классов образуют единую систему, а не дикую портянку из слабосвязанных и зачастую несовместимых между собой лефтпадов, которые нынче в моде?
Уж поверьте, я работал с ExtJS от старых версий и до довольно новых, а сейчас соседняя команда с таким скрипом пытается на реакт+mobx повторить всё что в прежнем UI подключалось парой строчек — что от их стараний полсистемы шатает. И время билда только за счёт jsx у нас почти на 40% подскочило, и это ещё ни один наш модуль не стал полноценно переходить на молодёжные фреймворки, которыми пользуется больше 0,5% разработчиков.
соседняя команда с таким скрипом пытается на реакт+mobx повторить всё что в прежнем UI подключалось парой строчек
О да, это вершина программирования. «Программировать» галочками и 2мя строчками копи пасты из примеров с сайта.
Кто же в здравом уме будет сам реализовывать алгоритмы и тем более вообще писать код, это удел дурачков и неудачников.
Вот они там и мучаются на своими реактами и т.п. ха-ха.
А вы делите пьедестал почета с 1Сниками и гордитесь этим =)
Вы кроме числа классов и платности про него что-то ещё знаете?Да, работал с ним до той поры пока он был бесплатным. До 5- версии.
Например, про огромное количество настроек и надстроек?Огромное. Согласен. Да и классов поди уже свыше 700 там. Если брать по 10 методов — то под 7000 методов то будет то, поди.
Или про то, что его формат функциональных таблиц толком никто не повторил с тех пор, и именно из-за таких таблиц проект вообще до сих пор шевелится?Да, если кому надо таблицы из Excel в веб закинуть, то возможно, не бесплатно, можно попробовать ExtJS — но сам я не использовал таблицы то. Не из банка я.
Или хотя бы про то, что все 500 или сколько их там классов образуют единую систему, а не дикую портянку из слабосвязанных и зачастую несовместимых между собой лефтпадов, которые нынче в моде?Верно. Никакой моды. Всё кондово сделано. Как в Дельфи!
ещё ни один наш модуль не стал полноценно переходить на молодёжные фреймворки, которыми пользуется больше 0,5% разработчиков.Согласен. Банки надёжно «подсели» на этот ExtJS, тем более что у банков денег хватает на лицензию то.
А может уже не 0,5% а меньше на рынке то у этого «динозавра» у ExtJS — я только видел что ниже плинтуса.
Но для банков это неважно — да и в банках дельфинариков хватает, чтобы освоить ExtJS то. Он им будет привычен. Кондовый ООП — это что-то!
И я не шучу!
(Разработчики ExtJS конечно наклепали и React библиотеку СВОИХ компонентов, то это мода, не более чем. На это можно, наверное не обращать внимание. — Кондовый дельфиподобный ООП — ExtJS — что ещё нужно банковскому программисту?)
И я не шучу!
Ну да, настоящие хипстеры, которые пишут на редаксе готовы работать исключительно на магазины по продаже вейпов. Для всего остального есть более адекватные технологии, но всё, кроме вейпов и не нужно. А если для интернета нужны только магазины по продаже вейпов, а их лучше всего писать на редаксе, то настоящий хипстер сразу смекнёт, что ничего кроме редакса в интернете не нужно!
но сам я не использовал таблицы то.
Но хаять их (выходит, безосновательно) это вам не мешает.
Так всё-таки, какие конкретно претензии к фреймворку? Меня количество классов и методов вообще не интересует (тем более что с количеством методов внутри вы ошиблись примерно на порядок), и у меня нет отвращения к Дельфи, ООП и тем, кто с этими технологиями работает.
Вы не понимаете. Сейчас не модно писать понятный и поддерживаемый код. Сейчас нужно побольше динамики, побольше меняющихся свойств, чтобы каждый раз, когда ты смотришь на переменную — она как женщина: Загадка!
А ещё ни в коем случае не реюзать код. Всегда проще закопипастить, ведь он может чем-то отличаться! Так и изменения вносить проще!
Ну и, конечно, "классы"! Это ведь мерзкое слово, почти как "сексист"! Даже если логично использовать класс — ты должен вывернуться и сделать то же самое, но без использования слова "класс".
Но хаять их (выходит, безосновательно) это вам не мешает.
ААААААААААААААААААААААААААААААААА!!!
Где я хаил таблицы? Какими словами или знаками препинания?
Я не работал с таблицами в ExtJS — ну НЕ пересекался никак.
Надо вам ООП как у Дельфи или таблицы — и заказчик в состоянии платить лицензию — используйте ExtJS.
Проблемы?
Меня количество классов и методов вообще не интересует (тем более что с количеством методов внутри вы ошиблись примерно на порядок)Ну а что ещё можно сказать о ExtJS? Уже всё сказано.
Ошибся я в какую сторону? 10 методов на класс — это много — там 100? Или мало — там по 1 методу на класс то?
А кроме методов у классов есть ещё и СВОЙСТВА — по 10 на класс.
Итого — 10 000 методов и свойств на 500 классов, примерно.
У вас другие цифры? — так озвучьте.
и у меня нет отвращения к Дельфи, ООП и тем, кто с этими технологиями работает.А я как-то обозначил отвращение к Дельфи и ООП?
Да у меня нет никакого отвращения и к Коболу!
Я написал что дельфинарики (программисты на Дельфи) вполне смогут ЛЕГКО начать писать код на ExtJS — там такой же кондовый (то есть ОСНОВАТЕЛЬНЫЙ) ООП что изучали в универах с середины 90-х годов прошлого века.
И я думаю, что дельфинарики ещё есть в банках то! Куда они смогли уйти то? На Java?
Я уверен что и функциональщина и даже Redux можно использовать в ExtJS (я подписан на рассылку ExtJS и там время от времени появляются упоминания что что-то такое делается и в ExtJS).
Так что НЕ надо на меня нападать за ExtJS. Я уже всё написал что знал про него.
Ну не пользуется ExtJS никакой популярносттью сейчас как и Дельфи — но если это кого-то не пугает, и не пугает плата за лицензию — то почему бы и нет?
Но, похоже, если я сейчас напишу что «два плюс два равно четыре», вы напишите мне в ответ (поставив минус посту) что типа Я ОБИДЕЛ ЦИФРУ ПЯТЬ!
Не надо так.
У вас другие цифры? — так озвучьте.
Меня вообще не цифры интересуют — а, например, то, что это цельная библиотека компонентов, с хорошим фактически никем не повторённым функционалом таблиц, при этом достаточно гибкая, чтобы на её базе хорошо работали совершенно по-разному выглядящие интерфейсы (несмотря на "кондовый ООП") — и даже допускающая степень модульности архитектуры, при которой вышестоящие интеграторы могут добавлять функционал в существующие компоненты/формы без создания компонентов "таких же, но с перламутровыми пуговицами" (во многом — благодаря "кондовому ООП").
А я как-то обозначил отвращение к Дельфи и ООП?
Да, прямо в следующем абзаце сообщения.
Я уже всё написал что знал про него.
У… Честно говоря, не густо. Похоже, я могу больше недостатков в ExtJS назвать, а я же даже на рассылку не подписан. А самое главное — вы так и не написали, чего вам в нём настолько не нравится, что такие эмоции сквозь текст проступают, а ведь именно такой был вопрос.
Надо вам ООП как у Дельфи или таблицы — и заказчик в состоянии платить лицензию — используйте ExtJS.
- Есть и бесплатные альтернативы ExtJS
- Если заказчик в состоянии платить за проф программистов, которые месяцам велосипедят то же самое на Реакте, то на лицензию у него есть деньги и подавно.
2) У некоторых заказчиков разное отношение к тратам на создание своей интеллектуальной собственности и на лицензирование чужой.
Есть и бесплатные альтернативы ExtJS…
на лицензию у него есть деньги и подавно.
Тут налицо противоречие — если есть бесплатные альтернативы то зачем платить?
Думаю «мощнее» по кондовости ООП и количеству классов нет альтернативы ExtJS.
Похоже главная причина почему ExtJS никто не рекомендует — это исчезающе малое число программистов желающих использовать ExtJS (и возможно и его кондовое ООП) на фронтэнде.
ExtJS спасают от забвения, похоже, банки, «подсевшие» на него до введения платной лицензии.
Сначала мы жалуемся что «Почему эти функции просто болтаются в коде, и почему они не инкапсулируются внутри классов сервисов, чтобы сделать их статичными?», а потом плачем о том что саги разбухли и непонятно что с ними делать. А понимание того что нужны сервисы — автоматически ведет к пониманию того что DI нужен если не в компонентах, то в самих сервисах и сагах — точно. Плач о именованиях файлов вообще клоунада, но напомню, что при одинаковом названии класса и файла — искать фултекст серчем — гораздо удобнее.
Например требование class based components на самом деле продиктовано желанием использовать inversifyjs в режиме аннотаций, когда function based components потребовали бы явно обертывать функцию перед экспортом или использовать реактовский аналог service locator-a (context).
Требование retry policy через PollyJS так же не совсем обычно для экосистемы реакта (есть другие инструменты).
И это без учета претензий по скорости разработки/билда и качеству собственноручно созданной архитектуры, которые совсем странные.
Эта история скорее о том, как люди не хотели договариваться и каждый тянул одеяло на себя… итог в виде рваного одеяла не заставил себя ждать.
1) Переносим имеющееся приложение с WPF, разработчики все тоже с опытом WPF
2) Берём максимально отличающуюся от MVVM технологию управления стейтом
3) ???????
4) Почему меня чуть не уволили?!
А ведь достаточно было не натягивать свою любимую сову на очередной глобус. WPF-разработчики прекрасно переезжают на связку React + MobX + Typescript, поскольку идеология организации кода и состояния практически 1 в 1 совпадают. Но Redux-сектанты будут упорно продавливать своё мнение, да.
Из фреймворков именно на C# сейчас для браузерной части SPA-приложений условно-пригодным является только Blazor, всё остальное использовать в продакшене нельзя в принципе никак и будет нельзя ещё года два минимум. Если вам кто-то про свою чудо-библиотеку говорит обратное, плюньте ему в глаз.
Production-ready технологии же относятся к серверсайд-рендерингу и для ряда приложений просто неприменимы.
Так что по состоянию на 2021 год C# в вебе может использоваться только на сервере.
Есть ряд решений на F# типа Fable, но это опять же слишком отличается по парадигме от WPF+MVVM.
Если еще добавить модификаторы доступа TypeScript (private, protected), то вообще проблем не будет.
Совершенно с вами согласен. В моем случае мы выбирали для Vue использовать класс компоненты или новый composition API похожий на хуки React. Конечно на Typescript. Хорошо что у нас есть немного разделение на фронт и бек. Но все по умолчанию фулстеки. В итоге на фронте пошли по пути функционального кодинга. А бек у нас на PHP Laravel и там ООП, паттерны, классы… Так вот даже учитывая, что PHP не такой строгий ООП язык как C#, Java — все равно бек разработчикам крайне сложно понять и принять фунциональщину. И не все уже смогли работать фулстек. Поэтому да, если разделения нет, надо настраивать фронт под бек, никаких функций, только классы.
А почему бы не вбросить разработчикам, привыкшим к ООП, упрощающие концепты, вроде того, что функция — это такой объект с классом, имеющий всего один метод и слегка необычные особенности вызова оного метода? Или вот, так как они привыкли к паттернам, то пояснять по аналогиям с паттернами, ведь большинство из них (например Стратегия) — это реализация идей ФП в окружениях, построенных по принципам ООП.
это реализация идей ФП в окружениях, построенных по принципам ООП
Скорее реализация в ООП идей, реализация которых в ФП не требуют каких-то специальных телодвижений. Если не говорить про стейтфулл паттерны )
Стратегия — это инверсия контроля путём согласованной подмены группы функций. На функциях (без объектов) это разве что через свичкейс реализуется.
Во-первых, группа функций, контролируемая Стратегией, может состоять из единственной функции, что позволяет делать Стратегию тождественной просто ссылке на функцию. Таким образом это может работать и без объектов, например в C.
Во-вторых, паттерн сам по себе не говорит, каким именно образом происходит выбор конкретной стратегии, это уже задача фабрики стратегий. А уже в фабрике можно и свитч, и словари, и много чего ещё.
А обезьяна — это такой глупый человек, потому что люди тоже бывают глупыми?
Свичкейс нужен не для выбора стратегии, а для переключения между аспектами одной стратегии: https://redux.js.org/tutorials/fundamentals/part-3-state-actions-reducers#handling-additional-actions
Видимо, у нас тут фундаментальное расхождение в терминах.
Вот моё определение — https://en.wikipedia.org/wiki/Strategy_pattern — здесь нигде не говорится про какие-то аспекты одной и той же стратегии. Более того, во всех блок-схемах и примерах стратегия с точки зрения use site состоит из единственной функции.
Где ваше определение? Эта ваша статья не содержит ни единого упоминания паттерна. Все сниппеты со свитчами — это вообще код фабрики. И даже если бы статья содержала слово "стратегия" — единственного примера из единственной библиотеки малость маловато для заключения, что паттерн всегда должен был именно как в этой библиотеке.
Я погуглил и… всё очень печально. Люди видят всего-лишь пример с одним методом и думают, что метод может быть только один. Ну, простейший пример — стратегия маршалинга, ей нужно как минимум 2 метода.
Это, кстати, и правда очень печально. Когда люди смотрят на паттерны — они не способны увидеть что-то большее, чем написано. Они не понимают, что это только приёмы, которые показаны на самых простых, вырожденных примерах и с них можно сделать что-то значительно более мощное.
А что ещё ожидать, если люди вынуждены учить паттерны, как я английский учил: The Present Perfect Continuous Tense выражает действие, начавшееся ранее и продолжающееся в момент речи или завершающееся к моменту речи. Образуется с помощью вспомогательного глагола to be в форме Present Perfect (have been, has been) и Participle I смыслового глагола — ночью разбуди тогда и ответил бы без запинки.
Люди видят всего-лишь пример с одним методом и думают, что метод может быть только один.
А вы опыт общения с другими людьми на меня не переводите. Я не говорил, что метод может быть только один. Я говорил, что он может быть только один.
Повторю второй раз, так как вы наверняка опять не прочитаете. Стратегия может быть с любым количеством методов, включая один метод. В случае стратегии с единственным методом, реализацию паттерна можно упростить до единственной ссылки на функцию, и в этом случае реализация не будет требовать никаких дополнительных объектов или структур, потому может быть реализована даже в процедурных языках с поддержкой ссылок на функции.
паттерна можно упростить до единственной ссылки на функцию
А в чём упрощение? Ну с точки зрения архитектуры какая разница — это функция в неймспейсе или метод в классе? То, что у класса слегка длиннее запись — лишь вкусовщина. Так в чём упрощение?
А в чём упрощение?
Очень маленькое упрощение, на самом деле. В одном случае у вас структура со ссылкой на функцию, в другом — просто ссылка на функцию (или аналог). Чтобы добраться до тела функции нужно сделать на один переход по указателю меньше (но за счёт этого по сути теряется возможность иметь более сложные каноничные стратегии из нескольких функций).
И тут я осознал, что React не дружественен ни к Java, ни к .NET разработчикам. Angular в этом случае был бы лучшим выбором из-за схожих шаблонов проектирования.
Это как? Депенденси инжекшен он и в африке… И если они бэкендистов заставили писать фронт, а не фуллстек/фронтенд разработчиков, то ожидаемо что они будут писать говнокод без энтузиазма. Хоть на ангуляре хоть на реакте.
И зря тут недооценивают разработчиков нет и жава. Сколько проектов видел написанных всякими жаваскрипт адептами которые раньше джеквери херачили. Зачем паттерны… это все овер, давайте без них. И быстро и кода меньше. А потом ни тестировать без магии жеста (Jest) ни поддерживать это гомно нельзя. Поэтому паттерны тут испортить ничего не могли, если естественно их применяли когда надо, а не паттерны ради паттернов.
Я никогда не видел двух проектов React с одинаковыми зависимостями, структурой проекта и руководящими принципами.
Ну если структуру делать feature based то она и на ангуляре разная будет.
А вообще такое чувство что просто недооценили сложность проекта учитывая что это новый стек для разработчиков, и думали щас как в ангуляре наклепаем формочек с двусторонним байндингом и крадом и в продакшен.
Вообще тут намешаны разные вещи не связанные с реактом от слова совсем. Билд берет время? Ну это проблема всей экосистемы ноды.
Могу согласиться только с тем что новые хуки и контекст добавляют магию и конвенции, и действительно не все их любят, включая меня. Ну и борьба с самим собой потому что на тебе лежит ответственность выбора библиотек, а не как в ангуляре — что дали тебе в фреймворке то и юзай. Хотя и там сторонних библиотек хватает. Redux это отдельная пестня…
Это как? Депенденси инжекшен он и в африке… И если они бэкендистов заставили писать фронт, а не фуллстек/фронтенд разработчиков, то ожидаемо что они будут писать говнокод без энтузиазма.
Заставили людей с опытом десктопного фронта на MVVM писать как завещали адепты Redux. Виноватыми оказались React и разработчики.
Обычно beckend разработка предполагает больше знаний, умений и ответственности. Поэтому не совсем понятно в чём должна быть сложность изучить и писать frontend, если стоит такая задача.
Обычно beckend разработка предполагает больше знаний, умений и ответственности
Как fullstack developer не могу с вами согласиться. Подавляющее большинство backend developer-ов занимаются более чем простыми вещами. Лишь немногие занимаются чем-то действительно интересным. Как например high-load-ом, сложными балансировками, большие смежными задачами.
Подавляющее большинство backend-разработчиков:
- знают SQL только на базовом уровне (знают про индексы, умеют писать миграции, умеют в join-ы и groupby)
- чаще всего используют ORM, чаще всего Active Record
- имеют отдалённое представление о системных вещах (вроде тонкостей работы сетевого стека, маршрутизации, работы с диском и т.д.)
- не пишут никаких сложных алгоритмов. По сути практически вся задача сводится к "взять из СУДБ записи по простому запросу, преобразовать их в другую структуру данных, отправить в виде JSON на клиент" и "взять из базы данны по 10-и запросам и собрать через либу в xls отчёт"
- пишут в рамках одной и той же парадигмы годами без изменений
- немного умеют в docker, k8s и смежные технологии
Разумеется из всего бывают исключения. И как только речь идёт о больших нагрузках и начинаются всякие шардирования — вот тут становится уже интересно и весьма непросто всё. Но таких контор минимум. Я думаю на 9 разработчиков уровня "гонять туда-сюда json" приходится 1 разработчик уровня серьёзного backend-а.
И я не могу винить в этом разработчиков. Просто рынку и в самом деле сейчас не нужен сильный backend в таком количестве. А в простом виде он ужасно скучен. И совсем несложен. Я почти отошёл от backend задач, во многом из-за того что он ужасно скучный. В то время как во frontend есть потребность в очень сложных приложениях. Challenge every day. Мы уже давно перешли в "эпоху" толстых клиентов.
В большинстве случаев из опытов на front могут взять студентов или же людей без профильного — риски запороть из-за этого проект минимальны.
И картина абсолютно противоположная с backend, риски намного больше и ответственность тоже и бекенд должнен быть достаточно абстрагирован от фронденда в большинстве случаев. То что вы сталкивались с разработчиками с базовым уровнем SQL, docker, паттернов не значит что это норма и стандарт в индустрии.
По крайней мере для серьезных проектов или энтерпрайз нужны хорошие знания языка, ООП, паттерны, многопоточность, конкурентный доступ к данным, синхронизация и тд.
У меня абсолютно противоположное мнение.
Ну вот и ошибаетесь. Вы сами пробовали писать клиент, или так — сосед напел? Особенно какие-то сложные приложения или, тем более, игры. Я вот делал сайт для донатов — там и админка (которая позволяет ползунками настроить любую структуру), и страниця для отображения — сложные, объёмные задачи. А из сервера самое сложное — не забыть залить его вовремя, да бекапы настроить.
Студентов берут и на бекенд, и на фронтенд, это не показатель. На фронтенде нужно больше совмещённых знаний — тут и тех артист, и математика, и куча разного клиентского железа и по. А на сервере — вплоть до того, что ты указываешь, какой процессор нужен. Но обычно на бекенде всё просто и оно работает приблизительно одинаково. Я уж молчу о том, что бекенд тестами покрывается значительно легче. Попробуй покрыть все клиентские сценарии, которые вообще не формализируются?
Количество знаний необходимых для фронтенда значительно ниже, ответственность ниже, при том, что я разрабатывал и небольшие игры, и очень сложные графические компоненты. Не вижу к чему вообще этот спор и почему вас так задевает. Я же пишу, что это мнение основанное на моем опыте и я привел аргументы почему так считаю, еще очень часто разработчик бекенд с легкостью переключается на frontend, а вот обратное бывает редко и обычно требует очень серьезного изучения технологий.
разработчик бекенд с легкостью переключается на frontend
Для полноценного переключения с backend-а на frontend потребуется, минимум года 2. И это если человек с хорошо работающей головой. И это будут мучительные 2 года.
обычно требует очень серьезного изучения технологий
Не требует. Не нужны обширные знания по многопоточности и механизмам синхронизации. Люди часто вообще таких слов не знают. Я вам напомню что большая часть backend-а это PHP, Python, Ruby, Node.js. Не нужны знания паттернов и SOLID. Потому что большая часть backend-а очень устоявшаяся вещь. Условный MVC framework на PHP имеет вполне конкретные guidelines, best practices, разделение на слои.
Серьёзных знаний по SQL тоже не требуется. Большую часть головняка снимает ORM. Даже виды индексов знать не надо. Даже виды транзакций большинству до одного места, т.к. народ просто тупо не пользуется транзакциями. Либо их СУБД в них не умеет :D
Потребуются минимальные знания про работу с файлами. На уровне: смотри вот это файловый дескриптор, вот fwrite, 1-ым аргументом дескриптор. И не забудь fclose. Всё, бери таску из jira и фигачь отчёты.
Знания виртуализации тоже нужны на уровне: чем docker run отличается от docker exec. ДевОпс остальное за тебя уже решил
Я вам напомню
И я напоминаю, что несмотря на GIL у Python есть полноценный мультитриденг и он успешно работает для IO операций в связке с event loop от asyncio. также можно в пару cтрочек выносить управление в отдельный процесс.
Серьёзных знаний по SQL тоже не требуется. Большую часть головняка снимает ORM
И после этого элементарный вопрос про уровни изоляции и конкурентный доступ вызывает у человека ступор. Если вы пишите для банков или даже элеметарные сайты продажи билетов, то уже необходимы хоть какие-то знания иначе получается по два человека на место, что я лично наблюдал.
И вот сами посудите, вы описываете, что практически никаких знаний не требуется на бекенд, но из вашего описания это уровень трейни или человека знающего программирование пол года.
По каждому из этих вопрсов написаны большие и толстые талмуды. Я могу себе только представить, что вы пишите простые сайты и поэтому у вас сложилось такое впечетление или же вас просто задевает и вы хвалите свое «болото». Так как entry level не вытянет бекенд, а фрондент успешно сможет именно поэтому даже из моего окружения множество перепрофилировалось из других профессий на фронтенд или QA automation, а на бекенд никого.
или же вас просто задевает и вы хвалите свое «болото».
Любопытно, что это у вас клиент пишут студенты и вы не видели хороших фрондэндщиков, а болото — у нас.
Я ничего про комманду не писал вообще, а вы фантазируйте. Я лишь выразил свое субьектинвное мнение основанное на опыте. Для меня ваши аргументы звучат все-равно что вы сейчас будете доказывать, что работа секретаря или QA сложней чем у программиста. Я понимаю, что она сложная и важная, но она проще. Учитесь не воспринимать в штыки другое мнение и слышать.
Ну у вас ведь вообще нету аргументов кроме "Бекенд это сложно". Вот вы говорите, что уходят с бекенда на фронтенд. Да, я вот первые 5 лет был бекендщиком и понял, что это — скучно, потому постарался переметнуться во фронтенд, ведь тут есть разные новые задачи, а в бекенде хотя я и не дошёл до верха — там всё то же самое. Ну да, выучил дополнительно пару технологий, но опять же просто фигачешь по шаблонам.
Ваша аналогия — глупая и я объясню почему.
Видите ли, бекенд — это ремесло, как рабочий, который клепает одинаковые гайки на заводе 30 лет. Да, это тяжело, это утомительно, этому надо научиться, но это не сложно.
Фронтенд же ж — скорее инженерия, когда у тебя нету готового решения. Тут реально появляются сложные новые задачи, но бекендищу и джун-фрондэндщикам этого не понять.
Бекенд — это словно зазубрить огромный талмуд, это реально тяжело. Фронденд — это словно такой талмуд написать. Да, это легче чисто психологически, ведь меньше рутины, больше творчества, но требует сильно больше интеллектуальной работы.
Вам стоит учиться слышать другие мнения кроме своего и поменьше волноваться из-за того, что не смогли осилить переход в более тяжёлую область.
Бекенд — это словно зазубрить огромный талмуд, это реально тяжело. Фронденд — это словно такой талмуд написать
Хорошая аналогия! Надо запомнить. Действительно, когда пишешь сложный SPA чувствуешь что пробиваешь головой стену. Никаких готовых к использованию решений. И большой спектр задач.
С одной стороны почти никогда не бывает скучно. С другой стороны вечный brain-storm.
Единственное что в этой ситуации может быть интересно это архитектура приложений.
Это всё зависит от подхода. Если на каждый эндпоинт копипастить типовой код, то это мало чем отличается от копипасты формочек на фронте. Я, например, делал такой бэкенд, где:
- Предметная область описывается простым конфигом, по которому автоматически поднимается БД.
- Есть всего несколько эндпоинтов, каждый из которых может работать с любой моделью по единым правилам.
- Fetch Plan определяется текущими потребностями клиента, а не хардкодится.
- Код модели шарится с фронтом — её не надо описывать дважды.
- Данные в реальном времени обновляются через сокеты.
- Подсписка на обновления и отписка происходят автоматически.
- Всё это шардится и реплицируется.
Не назвал бы это скучным закручиванием гаек. Не бывает скучный областей деятельности. Бывают скучные люди.
Я десятый раз пишу, что это основано на моем опыте и он субьктивный.
А вас настолько задевает и трясет, что вы мне приписываете и неумение во фронтенд (хотя это самое легкое что я вообще делал).
И то что нас много студентов в комманде, хотя их нет вообще.
Учитесь читать и слушать других.
Я не отрицаю что у вас интересные и сложные для вас задачи.
Я десятый раз пишу, что это основано на моем опыте и он субьктивный.
Ваш опыт очень плохо отражает объективную реальность. Но читать почему-то не умею я. Интересно.
Видимо то, что вы считали очень сложным и интересным для остальных программистов оказывается скучной рутиной и именно потому вы тут сопли развели и хнычите.
у Python есть полноценный мультитриденг
Да и в node-js можно с потоками писать. But why? Это точно не входит в перечень необходимых знаний для python\nodejs backend разработчиков middle (и возможно senior) уровней. А случае PHP вообще граничит с безумием и ненормальным программированием.
но из вашего описания это уровень трейни или человека знающего программирование пол года.
Не, никаких ни пол-года. Но года три в среднем достаточно. Для фронта мне кажется около 8-ми нужно.
что вы пишите простые сайты
Не я пишу. А backend программисты пишут. И да. Вы попали в самую точку. Большинство backend программистов пишут простые сайты. Вот прямо в десяточку. Не знаю как от вас эта простая истина ускользала все эти годы.
а фрондент успешно сможет
Не сможет. Не знаю таких случаев. Обратно — легко. Я провёл много собеседований.
QA automation
Вам не смешно сравнивать QA-automation c frontend? Вы выше писали про то, что вы full-stack. Мне кажется вы лукавите. Складывается впечатление что вы имеете очень отдалённое представление о современном frontend-е.
Складывается впечатление
Складывается ложное впечатление из-за того что вас задевает что кто-то считает что фрондент проще, а это ваша любимая сфера деятельности.
Но я уже десятые раз пишу, что спор не имеет смысла, для меня лично и для тех с кем я общаюсь он очень простой.
Кстати, если у вас вызывает именно сложность в изучении всех фреймворков, то это опять же с лихвой заменяется изучением базовых подходов и концепций. После этого любой новый фреймворк становится предельно ясным после прочтения документации, вы просто будете моментально знать как работает на фоне. Такие знания более полезны чем знания условного Vue.
Вы правда думаете что я не понимаю как устроен React и Vue? :) Сложность вызывает не изучение framework-ов, а умение с ними сварить кашу. В подавляющем большинстве случаев люди не могут выстроить разумную архитектуру. Ни разу не слышал о таких проблемах в популярных PHP-фреймворках. С ними вы начинаете приложение с того, что архитектура уже готова и она разумна. Главное придерживаться нескольких концептов.
Не только пробывал, но и постоянно занимаюсь фулстек разработкой энтерпрайз и мид сайз решений.
Ну тогда должны понимать, что бекенд разработка значительно легче фронтенд. Туда легче переключится, да и фрондендщики легко туда переходят в отличии от обратной. Не понимаю, почему у вас так горит с этого.
и множество вайтишников именно на фронтенд, будем считать это исключительно совпадением.
Ну да, ну да. Ведь так круто писать фронтенд на пхп и питоне. А на ДжаваСкрипт люди начали идти только когда он тоже осерверился
Я рад, что для вас это аргумент, что бекенд значительно легче.
Вот только JS появился в один год с ПХП и Питоном, а начали идти только когда стал популярный серверный. Причинно-следственные связи улавливаем?
Я вас удивлю, но эту историю я видел, писал и делал сам, а не прочитал в интернетике.
Я вас удивлю и дам исторический урок, но JavaScript и на фронтенде стал популярным относительно недавно с выходом jQuery.
На вашем месте я бы постеснялся в 2021 году имплицировать, что выход jQuery был "относительно недавно". Потому что в 2021 году выход jQuery относительно зарождения интернета был практически настолько же "недавно", что и относительно текущего момента.
и множество вайтишников именно на фронтенд, будем считать это исключительно совпадением.
Собственно дальше позиции верстальщиков из вайтишников мало кто уходит. А это не программирование.
Успешно справляются с React и Vue.
C React успешно справляется процентов 10% из тех кто на нём пишет. Оставшиеся 90% только думают, что что-то в нём понимают. Я проводил много собеседований и знаю о чём говорю.
Код этих 90% = write only. Именно после таких вот "справившихся" мы читаем очередной longread о том "как я внедрил в проект react и меня чуть не уволили". Концепции которые лежат в основе вменяемого React кода слишком сложны для подавляющего большинства разработчиков. Включая backend разумеется.
Большинство "react-разработчиков" даже документации не читали. SPA написанные ими настолько кривые что при росте бизнеса приходится всё выкидывать и начинать писать с нуля, уже руками тех людей, кто понимает как это всё работает.
С Vue точно такая же петрушка. 99% "Vue разработчиков" (мне даже сам термин %framework%-разработчик противен) даже не знают как работает observable. О результатах я думаю вы догадываетесь
Вот только в случае с Angular есть какие-то надежды. Костные framework-и, где за вас уже всё решили — они пригодны для начинающих. Меньше шансов выстрельнуть в ногу = хорошо. К тому же он ближе к типичным backend концептам.
C React успешно справляется процентов 10% из тех кто на нём пишет. Оставшиеся 90% только думают, что что-то в нём понимают. Я проводил много собеседований и знаю о чём говорю.
Я думаю вы преувеличиваете, мой опыт говорит что от силы 5%. Истина где-то посередине =)
Оставшиеся 90% только думают, что что-то в нём понимают.
Про что я и писал выше. Ситуация на рынка такова, что такое качество допустимо и поэтому много вайтишников, и поэтому достаточно даже 5% чтоб начать. Но вот опять же, выбросить через год cайт, это не тоже самое, что выбрость core функционал.
Ситуация на рынка такова, что такое качество допустимо
Т.е. то что на рынке есть конторы которые готовы нанимать абы кого, чтобы писать абы что, и потом это выкидывать через год… Заставляет вас думать что frontend простой? :)
Desktop разработка переехала в web. А она всегда была довольно сложной и разнообразной. И теперь ею занимаются front-ы. Это подразумевает довольно сложный UI. На рынке просто элементарно не хватает хороших специалистов. В итоге людям приходится довольствоваться тем, что есть. Получаются кривые тормозящие решения. Это то самое следствие того, что вам тут все пишут. То что фронтенд стал сложным, а разработчиков которые в него умеют — слишком мало.
В большинстве случаев из опытов на front могут взять студентов или же людей без профильного — риски запороть из-за этого проект минимальны.
Возможно мой опыт нерелевантен, но я последние годы работал над проектами, куда не только студентов не возьмёшь, а вообще разработчиков уровня ниже senior-а лучше не брать. Да и senior-у вникать пару месяцев, прежде чем он выйдет на окупаемость. Про студентов я вообще молчу. Они действительно не смогут запороть проект, т.к. я не могу дать им вообще никаких задач. Признаюсь я вообще не знаю как можно выстроить архитектуру большого SPA так, чтобы junior мог приносить больше пользы, чем вреда. Наверное я дурак. А может web свернул не туда. Но правда — всё слишком сложно.
А вот на backend-е я вполне себе представляю задачи под junior-а. Например — напиши endpoint который по ID товара делает запрос в базу, трансформирует результат в такую-то форму и передаёт на клиент в таком-то виде. Сделай по аналогии с вот этим местом. И покрой тестом. Пример теста вот здесь. Там почти копипаста.
риски намного больше и ответственность
??? Почему выше риски? XSS сопоставимы с SQL инъекциями по уровню наносимого ущерба. Это если вы про безопасность. А если про ущерб бизнесу из-за багов — то не так важно где баг сломал функциональность на клиенте или на сервере. Если что-то не работает, то бизнес теряет деньги.
многопоточность
Огромная часть бакенда это PHP, python, ruby. О какой многопоточности вы говорите?
для серьезных проектов
Коих абсолютное меньшинство
энтерпрайз
Вот только сказки про сложный ынтерпрайз не надо рассказывать. Все мы знаем насколько он чаще всего ущербен и примитивен. И как люди его избегают, чтобы не деградировать. Понятно, что бывает и по-другому, но как правило ынтерпрайз = дно.
конкурентный доступ к данным, синхронизация
В подавляющем большинстве случаев бакенд-разработчик может даже не знать таких слов и прекрасно справляться со своими должностными обязанностями. Come on, зачем вам это в связке "запрос в базу — отправить json на клиент".
ООП, паттерны
Не нужно всего этого знать. Для большинства backend проектов уже есть готовые матёрые framework-и где всё за вас продумано. Будь это Symphony, или Play или Django. Открыл документацию, почитал правила нейминга и как делить код на слои, посмотрел на примеры кода, посмотрел как другие ребята пишут в проекте — и понеслась.
Пожалуйста не путайте сложный замороченный backend, которого исчезающе мало, и обыкновенную монотонную работу по перекладыванию json-а.
В противовес этому на фронте есть множество замороченных паттернов и даже очень опытные разработчики не могут придти к тому как это всё правильно писать и связывать. На рынке frontend-а хаос, джунгли, полная анархия. Нет никаких best practice. Любая информация, которая сейчас рассматривается, как незыблемая истина, завтра считается мусором. Особенно если речь идёт про React. В случае React каждая контора пишет какой-нибудь свой универсальный велосипед, собирая его как конструктор, на лету изобретая его части. Это правда действительно очень сложно.
А зачем если можно не зная ничего (судя по вашем описанию) шлепать простые сайты и получать деньги. Я не осуждаю, просто вы должны понимать что есть разные проекты, мне, например, попадались всегда громадные и сложные.
То что вы описываете это абсолютная деградация отрасли
Для того, чтобы деградировать нужно, чтобы было чему деградировать. Серверная разработка, как более простая быстро была строго формализована и лучшие инженерные решения были давно открыты и посвеместно приняты. Клиентская разработка, увы, порядком сложнее и потому сама по себе теория для неё до сих пор продолжает расти.
Энтерпрайз это где основные деньги, а избегают этого просто из-за того что нужно именно что-то знать)
O_o. WAT? Что-то знать для ынтерпрайза? Зачем?
Я не осуждаю, просто вы должны понимать что есть разные проекты, мне, например, попадались всегда громадные и сложные.
Громадный != сложный. Громадный почти всегда = говнокод + legacy + кривая архитектура. Громадный = много команд разработчиков = большое количество бюрократии, дурака-валяния, подковёрных игр, идиотических поступков ради премий. Громадный обычно = устаревшие технологии, огромный технический долг, очень низкий уровень разработчиков.
В ынтерпрайзе платят больше в первую очередь "за вредность". Человек приходя на такой проект знает что будет больно. Что его знания и опыт помножат на ноль и заставят чинить кривые велосипеды путём расставления ещё большего количества кривых костылей. В ынтерпрайзе лучше как раз не знать. Тогда говнокодить будет не больно.
Один из моих бывших шефов сказал гениальную фразу: программисты приходят в банки чтобы умирать (как специалисты). Один мой знакомый программист из банка пару лет назад хвастался что смог уговорить руководство и внедрить git. До этого у них СУВ вообще не было.
Ну и нет тут никакой деградации отрасли. Всегда так было.
кривая архитектура
Это совсем не так, если бы так было, то их бы не могли поддерживать годами, а это происходит.
Обычно архитектура таких приложений всегда продумана и отточена, легко покрывается тестами, легко масштабируется.
Поэтому автобусы ездят, самолеты летают, банкоматы выдают деньги и интернеты ваши вообще бегают.
Но не суть, я представляю, что бывает иначе и ваш знакомый попал на такой случай.
то их бы не могли поддерживать годами, а это происходит.
вот вам моя любимая паста про Oracle:
Oracle Database 12.2.
It is close to 25 million lines of C code.
What an unimaginable horror! You can't change a single line of code in the product without breaking 1000s of existing tests. Generations of programmers have worked on that code under difficult deadlines and filled the code with all kinds of crap.
Very complex pieces of logic, memory management, context switching, etc. are all held together with thousands of flags. The whole code is ridden with mysterious macros that one cannot decipher without picking a notebook and expanding relevant pats of the macros by hand. It can take a day to two days to really understand what a macro does.
Sometimes one needs to understand the values and the effects of 20 different flag to predict how the code would behave in different situations. Sometimes 100s too! I am not exaggerating.
The only reason why this product is still surviving and still works is due to literally millions of tests!
Here is how the life of an Oracle Database developer is:
Start working on a new bug.
Spend two weeks trying to understand the 20 different flags that interact in mysterious ways to cause this bag.
Add one more flag to handle the new special scenario. Add a few more lines of code that checks this flag and works around the problematic situation and avoids the bug.
Submit the changes to a test farm consisting of about 100 to 200 servers that would compile the code, build a new Oracle DB, and run the millions of tests in a distributed fashion.
Go home. Come the next day and work on something else. The tests can take 20 hours to 30 hours to complete.
Go home. Come the next day and check your farm test results. On a good day, there would be about 100 failing tests. On a bad day, there would be about 1000 failing tests. Pick some of these tests randomly and try to understand what went wrong with your assumptions. Maybe there are some 10 more flags to consider to truly understand the nature of the bug.
Add a few more flags in an attempt to fix the issue. Submit the changes again for testing. Wait another 20 to 30 hours.
Rinse and repeat for another two weeks until you get the mysterious incantation of the combination of flags right.
Finally one fine day you would succeed with 0 tests failing.
Add a hundred more tests for your new change to ensure that the next developer who has the misfortune of touching this new piece of code never ends up breaking your fix.
Submit the work for one final round of testing. Then submit it for review. The review itself may take another 2 weeks to 2 months. So now move on to the next bug to work on.
After 2 weeks to 2 months, when everything is complete, the code would be finally merged into the main branch.
The above is a non-exaggerated description of the life of a programmer in Oracle fixing a bug. Now imagine what horror it is going to be to develop a new feature. It takes 6 months to a year (sometimes two years!) to develop a single small feature (say something like adding a new mode of authentication like support for AD authentication).
The fact that this product even works is nothing short of a miracle!
I don't work for Oracle anymore. Will never work for Oracle again!
И это Oracle. В конторах попроще всё ГОРАЗДО хуже. Вы 1-ый программист на всём моём жизненном пути, кто вообще отзывается об ынтерпрайзе в позитивном ключе.
Вы 1-ый программист на всём моём жизненном пути, кто вообще отзывается об ынтерпрайзе в позитивном ключе.
Если серьезно, ынтерпрайз бывает разный (даже в банках). Есть ынтерпрайз по типу того, что у вас в лонгриде про оракл. У него простые признаки:
1) он приносит деньги и продолжает приносить деньги
2) он древний, как говно мамонта, и продолжает быть таковым
Такой энтерпрайз практически всегда скатывается к тому, что описано в лонгриде — к стройной, и устоявшейся веками системе костылей, велосипедов, и подпорок. Которую невозможно переписать, а попытки поддерживать — вызывают рак мозга.
Но есть и другой энтерпрайз: главным образом то, что денег не приносит (или приносит немного относительно вышенаписанного). Вот там всё намного лучше, как правило — без постоянного давления бизнеса там всё чуть свободнее, программисты не всегда работают на дедлайны (а иногда на качество), да и вообще продукт как правило можно переписывать, не опасаясь быть уволенным.
Ergo, если работать в энтерпрайзе — главное, не работать на прибыльных и сверхприбыльных проектах. А вот на загибающихся, внутренних, или только же зарождающихся — вполне.
Признаюсь я вообще не знаю как можно выстроить архитектуру большого SPA так, чтобы junior мог приносить больше пользы, чем вреда. Наверное я дурак.
Да нет, вы просто $mol не пробовали, поэтому и не знаете. Тут всё просто:
- Инкапсуляция. Не сокрытие, а именно инкапсуляция, когда ты берёшь компонент и просто его используешь без приседаний вокруг импортов, сторов, DI и тп.
- Минимум абстракций. Простые абстракции. Классы, реактивные свойства, контекст окружения — этого уже достаточно.
- Разделение на слои. Модель отдельно, логика отдельно, композиция компонент отдельно, оформление отдельно. А не вперемешку, как в Реакте.
А вот на backend-е я вполне себе представляю задачи под junior-а. Например — напиши endpoint который по ID товара делает запрос в базу, трансформирует результат в такую-то форму и передаёт на клиент в таком-то виде. Сделай по аналогии с вот этим местом. И покрой тестом. Пример теста вот здесь. Там почти копипаста.
На фронте будут такие задачи по нарастающей:
- Поправь стили у такой-то группы компонент, чтобы выглядело так-то. Квалификация: стилизатор.
- Собери такой-то компонент из вот этих вот, чтобы проходил такие-то тесты. Квалификация: компоновщик.
- Вот тебе пример использования компонента, реализуй его, чтобы работал. И тесты не забудь. Квалификация: реализатор.
- Вот тебе макет, реализуй страничку, чтобы было похоже. Квалификация: разработчик.
- Нужна какая-то штука, чтобы упростить работу с такими-то типами задач. Квалификация: проектировщик.
При этом каждый может делегировать соответствующую часть своей работы фронтендеру меньшей квалификации и, соответственно, помогать ему расти.
Сам уже 4 года жду какую-нибудь разгромную статью про то, как в $mol всё плохо, но пока глухо.
Вот тут есть неплохая подборка постов на эту тему: https://habr.com/ru/users/vintage/posts/
Открыл документацию, почитал правила нейминга и как делить код на слои, посмотрел на примеры кода
Вот в случае примеров кода Symfony в разделах про СУБД сплошные антипаттерны, потому что показывают как из фреймворка достучаться до слоя данных, а не как его организовывать.
антипаттерны
антипаттерны тоже паттерны ;)
Формально, да. На практике это "как надо делать" и "как не стоит делать без чёткого понимания плюсов и минусов". А так 90% проектов на Symfony с Doctrine будут содержать анемичные модели из геттеров и сеттеров потому что так в документации и даже средства кодогенерации для этого есть
Умная модель, абстрагирующая остальные слои от деталей хранения, а не размазывающая их по всей кодовой базе.
Сущности Доктрины моделируют сущности предметной области, а там, обычно, нет операций типа "установить статус заказа в "Доставлен" или "Отменён"". Order::setStatus(Order::STATUS_CANCELED) отклоняется от предметной области и нарушает инкапсуляцию модели. Просто Order::cancel();
На самом деле в предметных областях очень много именно "статусов", а не вязанки cancel/reopen/reorder/resign и тд. Ибо многие переходы обратимы, а многие пропускаемы. В итоге на 10 статусов может быть до сотни переходов. И отдельно описывать каждый из них — это удавиться можно. Тут гораздо лучше работает разделение на "требования для перехода в нужный статус" (например, товар не отгружен, счёт оплачен) и "намерение перейти в нужный статус" (например, хочу, чтобы заказ был отменён).
Одно другому не мешает, метод cancel может быть примерно таким:
public function cancel(): void
{
if ($this->canStatusBeChangedTo(self::STATUS_CANCEL) {
$this->changeStatusTo(self::STATUS_CANCEL);
} else {
throw new \DomainException("Order can't be canceled");
}
}Или вы что-то другое имели в виду?
И какой смысл заводить 100500 методов с одинаковым содержимым, отличающимися лишь константами?
Для инкапсуляции конкретной реализации, и для того, чтобы все места, где Order может быть отменён, делали это одинаковым (правильным) образом, а не как придётся.
Отмена из разных состояний — это совсем разные процессы. Единственное, что их объединяет, — это конечное состояние.
Не "отмена из разных состояний" — а "отмена из разных мест в коде". Отменяться заказ может как прямой командой пользователя, так и реакцией на событие или вообще по истечению времени — и все эти случаи лучше привести к единому order->cancel(), чем иметь повсюду разные случаи прямых вызовов order->setStatus(CANCELLED), которые неизбежно в итоге разойдутся и будут выглядеть по-разному и содержать разные баги.
order->cancel() ничем принципиально не отличается от order->setStatus(CANCELLED) кроме возможности во втором случае иметь обобщённую логику, вместо копипасты.
Почему из order->cancel() хоть как-то следует копипаста?
Я вас не понимаю. И что? Вы предлагаете не писать код, который должен исполнятся при переходе в статус CANCELLED?
"Если юзер использует наше приложение не так, как задумал программист — он сам дурак", правильно?
Я предлагаю писать обобщённый код, а не копипастить типовой код на каждую проводку. Ну, подумайте над системой, где админ может накликивать бизнес процесс. Это предел обобщённости. Там не может быть никаких методов order(), а энам со статусами вообще в базе хранится. Даже если не нужна такая гибкость, проект куда проще развивать, если это все не хардкодить.
order->cancel() ничем принципиально не отличается от order->setStatus(CANCELLED)
Ну как это не отличается? Допустим, в вашей системе при отмене ордера должно так же отменяться всё планирование поставок, логистики, складских операций. Допустим, для упрощения, что всё напрямую не связанное с ордером выносится в другие домены через события. Тогда в псевдокоде:
cancel()
fun cancel():
if not this->canBeCancelled() then:
throw UpdateError('Order can not be cancelled')
end
this.status := OrderStatus.Cancelled
storage->flush(this)
evenBus->fireEvent(OrderCancelled(this))
endА в случае с setStatus будет примерно вот так:
fun setStatus(OrderStatus value):
eventType:= Nil
if value == OrderStatus.Draft then:
...
elif value == OrderStatus.New then:
...
elif value == OrderStatus.InProcessing then:
...
<!--думаю, так уже достаточно понятно-->
elif value == OrderStatus.Cancelled then:
if not this->canBeCancelled() then:
throw UpdateError(
'Order can not be cancelled'
)
end
eventType := OrderCancelled::Ref
else
throw UnknownOrderStatus(value)
end
this.status := value
storage->flush(this)
eventBus->fire(eventType->create(this))
endПри этом в первом варианте если типы можно абстрагировать, то может быть вообще примерно так:
fun cancel():
this->runStatusChange(
this.canBeCancelled::Ref,
OrderStatus.Cancelled,
OrderCancelledEvent::Ref
)
endА вот во втором случае от if ... elif ... elif ... else (или аналогичного switch) избавиться уже далеко не так просто.
Ну вот вы в конце и пришли к обобщённой функции runStatusChange, параметризированной статусом. Теперь вы можете сделать ещё один шаг:
fun setStatus(OrderStatus status):
this->runStatusChange(
status.Allow,
status,
status.Event,
)
endА потом ещё один, и убрать этот runStatusChange совсем.
А от ветвлений вы никак не избавитесь в любом случае, ибо они приходят из предметной области. В лучшем случае удастся упаковать это в стратегии, получаемые на основе текущего статуса и целевого.
status.Allow, status.Event
Так детали реализации протекут к пользователю. Если паковать в стратегии, то можно получить что-то лучшее чем оба варианта выше, но как правило система не настолько гибкая, чтобы оправдать внедрение подобных стратегий сходу.
Я не понимаю, на что именно вы возразили, честно говоря.
Обобщённый объект — это который из двух? Order? Или OrderStatus? Если второе, то как раз плохо то, что стратегия является частью статуса — а это значит, что мой домен ей, вообще-то, не может доверять, если все возможные стратегии не известны заранее и сам объект конструирует кто-то за пределами домена.
Что-то я пропустил главную вашу фразу. Вот эту:
То что вы сталкивались с разработчиками с базовым уровнем SQL, docker, паттернов не значит что это норма и стандарт в индустрии.
Причём тут разработчики? Я вам про рынок говорю. Огромный процент backend разработчиков пишут весьма примитивные backend-ы для весьма примитивных сервисов. Ну come on. Большая часть бакенда в мире это просто 1 mysql/postgresql база, какой-нибудь Symphony или Django, и 50-200 endpoint-ов, из которых 90% это перекладывание JSON-а.
Я как раз сталкивался с крутыми backend разработчиками. Например я сейчас работаю в конторе, которая пишет отказоустойчивый high-load backend в облаке, на микросервисах, с шардированием, нестандартными решениями, и прочем фарше. И да, в FP парадигме.
Просто я прекрасно понимаю, что это даже близко не норма. Это "крутой уровень", и крутые интересные задачи. Открывая на бирже труда "backend developer" вы вместо этого скорее увидите "Middle/Senior PHP developer. Laravel min. 3 years". Получив offer будете клепать одинаковые web-проекты под копирку. Даже тесты, вероятно писать не будете, ибо финансово неоправданно. Весь code — write only.
Это "крутой уровень", и крутые интересные задачи
И этот уровень всё-равно достичь легче, чем уровень клиентщика в сложной игре. По сути там несколько принципиальных концепций выучить надо, да и по библиотекам уже всё более-менее устоялось, сделал такой сервис один раз — остальные разы уже по накатанной
Вы вероятно невнимательно меня читаете. В моей текущей конторе как раз и работают весьма толковые backend программисты, которые пишут сложный high-load backend. И у нас на кухне разговоры про шардирование, property based testing, алгебраические эффекты, FP, всякие тонкости реализаций DI и пр.
Но я прекрасно понимаю насколько это редкий case. Типовой backend = перебрасывание json из базы на клиент и обратно. Это просто факт. Зачем вы пытаетесь это отрицать?
property based testing, алгебраические эффекты, FP, всякие тонкости реализаций DI и пр.
Но ведь все эти вещи обсуджают и клиентщики, плюс… куча всего дополнительного.
Да :) Всё так. Но я бы не стал так умалять заслуги серьёзного backend-а. Помимо своего головняка, у них там много всяких хитрых side-задач из нерелевантных областей. Могут припахать и какой-нибудь ML писать. Была бы голова на плечах, а чем её загрузить — найдётся. Не важно какая область. У нас backend на scala2, а это коммьюнити очень одарённых "извращенцев". Они себе геморрой на голову всегда придумают :D
Толковые программисты, как раз-таки стараются сделать всё как можно проще, а не тащить в проект все самые хайповые концепции, чтобы вводить в проект нового разраба нужно было 2 месяца.
Легко сказать, да трудно сделать. Я конечно понимаю, что у вас святая вера в то, что ваши решения простые, правильно выстроенные, и вообще $mol впереди планеты всей.
Но, исходя из сотен ваших сообщений, складывается ощущение, что это всё так только в вашей голове. И при любой критике выясняется что все ошибаются, не правильно мыслят, не под тем углом смотрят, не теми линейками меряют.
И применяют демогагические приёмы в дискуссии, да. Типичная ситуация, когда нечего привести в пример архитектурной сложности и кривизны. Ибо чтобы вести аргументированную дискуссию, надо разобраться в предмете обсуждения. Куда же проще вместо этого обвинить оппонента в слепой вере. Это не делает ваши слова сколь-нибудь весомыми.
С интересом слежу за вашей дискуссией, и у меня возник один вопрос:
Kromeshnaja, а вы точно не автор этой статьи завели себе второй аккаунт?
У меня небольшой React проект из коробки в продакшене билдится больше 15 минут (кстати с ангуляром этого не происходит, а и там, и сям вебпак) и это моментально вызывает вопросы.
Если вам смешно и вы считаете этой нормой, и не понимаете почему бумеры что-то там нервничают.
То я вам предлагаю просто пообщаться с заказичками и вы увидите, что иногда для бизнеса это не очень то приемлимо.
Если вам смешно и вы считаете этой нормой, и не понимаете почему бумеры что-то там нервничают.
Нам не смешно. Нам грустно. Оно может работать быстрее на 1 десятичный порядок не потеряв в функциональности. В наших инструментах даже AST между собой разные. Всё написано гибко, но крайне непроизводительно.
Для сравнения — парсер и транспайлер для JS/TS написанный на rust (правда без резолвинга типов) работает в 100 быстрее аналогичного в babel.
Нет, это не норма. Это грустно.
С одной стороны я тоже не в восторге от текущей ситуации и хотел бы переехать в webpack на esbuild.
Но в то же время, все мы помним историю libsass
- Появляется энтузиаст, который пишет нативную имплементацию, супер быструю
- Инициатива радостно приветствуется сообществом, кто ж не хочет ускорения билда почти забесплатно
- При этом PR-ы сообщество не присылает, потому что нужно не только разбираться в SASS, но еще и в CPP и алгоритмах, чтобы держать на уровне планку производительности
- Через какое-то время запал изначального создателя угасает, а заменить его некем
- А фичи все равно допиливать надо, тут и CSS-variables появились, и новый формат SASS-модулей
- В результате проект закрывается потому что поддерживать его некому.
Каковы шансы, что та же самая история не повторится с esbuild и каким-нибудь будущим стандартом ES2025?
Получается такая ситауация:
- Вы считаете что во фронтенде нет сложных задач, джуниоры справятся со всем
- И тут же приводите пример, что все-таки не со всем
Кажется ответ напрашивается сам собой – задачи для фронтенд-сениоров есть, с которыми справится не каждый.
То есть если вы решили задачу на бекенд-фреймворке, то вы научились писать качественный и продуктивный код, а если сделали то же самое на реакте, то нет. Почему такая разница?
С чего начинали
Обычно beckend разработка предполагает больше знаний, умений и ответственности. Поэтому не совсем понятно в чём должна быть сложность изучить и писать frontend, если стоит такая задача.
Чем закончили
Нет разницы, нужно понимать суть
Обе цитаты ваши.
В моем мире бекенд задачи как были сложней так и остались, и я писал, что это сугубо мое личное мнение (и по крайней мере тех с кем я общаюсь). Я думаю что те кто считают иначе просто не понимают обьема необходимых знания для решения повседневных задач или же занимаются простыми сайтами где этих задач просто нет.
А в изучении фреймворков противоречия нет, нужно учить, что тут поделать и подход примерно одинаков и учить проще есть есть хорошее понимание языка и архитектуры.
Фундаментальную архитектуру знать нужно, не спорю, но откуда у вас берется предвзятое мнение, что фронтендщики этого не знают?
И вы можете перефразировать вообще почему у меня предвзятое отношение к фронтенду. Ответ я писал выше, не вижу смысла описывать снова и снова.
Мне кажется всё упирается в следующие вещи:
Вы рассматриваете в качестве типичного backend разработчика человека, который работает на большим и сложным приложением. Которое использует несколько разных баз данных. Которое разбито на 10+ микросервисов. Которое имеет сложную контейнеризацию. В компании работает как минимум 1 dev.ops, который шаманит k8s. Почти все сервисы шлют сообщения в кафку, выворачивают redis на изнанку. Для всех популярных сущностей используется шардирование. Всё это тщательно покрыто разноуровневыми тестами. Приложения написаны на Java/Scala/C#/Haskel. Разумеется многопоточные. Требуется высокая отказоустойчивость. Разумеется это сложно.
А в качестве frontend-ера вы рассматриваете человека который занимается html/css вёрсткой, гоняет на backend и обратно json-ы. И его приложение это что-то вроде гостевой книги, корзины и формы оплаты в интернет-магазине. Ну, скажем, условный Amazon. Ну он правда несложный с точки зрения frontend-а. Или yandex.market-а (уже посложнее, но всё равно ничего особенного).
Если это так, то вы правы. Но у такого человека (фронтендера) требуемые навыки по большей части состоят из навыков верстальщика.
А мне под senior frontend developer-ом выдится человек которые пишет Google Docs, Facebook, GMail, Google.Maps и прочие SPA. Тут ключевые три буквы SPA = Single Page Application. Это то что мы раньше видели как десктопные приложения (условный Photoshop, After Effect, видео редакторы, офис и пр.). Вот это всё долго и уверенно переезжает в браузер. Это действительно большие приложения, с огромным количеством форм, экранов и тонкостей в UI.
Когда вы видите условный Instagram, вам может показаться — ну что такого сложного в том чтобы показать десяток картинок. Но если вы заглянете под капот вы сильно удивитесь, насколько сильно замороченным может быть показ десятка картинок. Для примера, из-за того что тег <picture/> это дикое позорище, а вовсе не, responsive image control, мне пришлось потратить неделю на написание своего, который по-настоящему responsive.
В сложном UI обычная кнопка может вызывать неделю споров о том, как организовать его архитектуру, и две недели реализации (с многочисленными правками и переобуваниями в воздухе). Хотя с виду кажется, что там делать нечего, это же ведь обыкновенный <button/>, чего там обсуждать.
Современный frontend бывает сложным как в мелочах, так и в архитектуре. 2-ая часть вообще кромешная беда фронта. Если пишешь приложение хотя бы под 50к LOC+ (да это одно frontend приложение, одна страница), то в попытке построить архитектуру сломаешь много копий и пару раз всё перепишешь.
Вот вам не придёт же в голову говорить, что 2GIS, Google.Docs или Google.Earth это простые приложения не требующие широких познаний во множестве областей? А это тот самый frontend. И вышеупомянутая вёрстка тут на фоне общих задач даже не отсвечивает. И вот очень странно читать сообщения про то, что фронтенд простой и его осилит даже самый тупой. В то время как из 100 кандидатов на вакансию хорошо если 1 что-то умеет. И ещё это всё странно читать когда народ уходит из backend-а устав от его скучных задач (мало кто сталкивается с вышеописанным сложным backend-ом).
Вы писали про банки. В банках я пока не встречал сложных приложений. Больших — да. Сложных нет. Немецкие банки легко обходятся самые древними web технологиями и в ус не дуют. Тот же самый Commerzbank. Даже переменные на немецком. Технический stack — каменный век. Типичный ынтерпрайз. Если оценивать сложность фронтенда по таких вот проектам то и правда окажется, что можно брать джунов с улицы и посылать на передовую. Вся передавая какая-нибудь говно-лапша на jQuery.
Вы сейчас на полном серьёзе утверждаете что Google Docs несложен? И что его бакенд часть требует бОльших компетенций? О_о.
Мне кажется у вас очень посредственное представление о задачах, которые решают любые фронтендеры. Будь то desktop/android/ios/web разработка.
Интересно, кому вы врёте — себе, ведь не хотите выходить из своего мирка обожествления бекенда и хейта фронтенда или нам, ведь не хотите признавать, что написали глупостей?
Я вас в десятый раз призываю учиться читать и не придумывать то чего вам не писали. Вы как программисты должны точно воспринимать то что вам говорят.
Я ни разу за все посты не обожествлял бекенд и не разу не хейтил фронтенд. Вы просто воспринимаете чужое восприятие сложности как хейт, откуда такие комплексы?
Перестаньте заниматься ерундой.
Ладно-ладно, давайте без истерик. Видимо я необъктивен, а вы правы, что Гугл Доки — это примитивный клиент и любой серверщик такую фигню за три дня сделает. И в этом никакого хейта.
Ну вот я и говорю — либо вы абсолютно не понимаете, что там за объём работы, либо врёте
Вы делате множество ложных выводов, просто из-за того что вас обижает мнение, убавьте пыл, выключите подростка и перестаньте бесперспективно доказывать в интернете что кто-то не прав.
Вы делате множество ложных выводов, просто из-за того что вас обижает мнение, убавьте пыл, выключите подростка и перестаньте бесперспективно доказывать в интернете что кто-то не прав.
Вот давайте счёт на табло, так сказать
Я высказал свое мнение, не привел аргументов.
Вы высказали свое мнение и не привели аргументов.
Но в отличии вас я не жду и не требую от собеседника передумать или согласится — в этом и есть та самая загвоздка.
Вы просто в какой-то момент сами поняли, что уже перегнули и начали полные глупости говорить и хотите теперь слиться так, словно и не упали в грязь лицом.
Я в этом глупости не вижу, и это подкреплено моим личным опытом, который у вас может быть совершенно другим.
Подумать, что фронтенд на Google Docs у бекендера занял бы меньше времени чем бекенд — да, несусветная глупость.
Это все сложней и объёмней написать чем SPА application и если вы сейчас будете приводить какие-то примеры форм или сложностей, то не забывайте что на каждый чих вы вызываете API где и реализована основная логика.
Ну, одним словом, вы не знаете, чем там занимаються эти фрондэндищи — потому значит они нифига не делают.
Я два года пилил убийцу гуглдокс, так что могу поделиться впечатлениями из первых уст...
На фронтенде не нужно запариваться про безопасность
Нужно. Как минимум нужно отсекать небезопасные ссылки в документе, чтобы они при клике не запускали произвольный код на исполнение. А так же фильтровать то, что в документ может накопипастить пользователь.
про контроль версий документа
Необходима реализация undo/redo, которая откатывает лишь действия текущего пользователя, но не других пользователей. При этом действовать она должна мгновенно и не зависеть от размера документа и истории.
про уровни изоляции БД
Необходимо накатывать изменения других пользователей так, чтобы не потерять собственные и так, чтобы у всех пользователей состояние документа сходилось к одному и тому же. Конкретно в гуглдокс используется OT, но они уже пожалели об этом. Есть алгоритмы проще, но и с ними много подводных камней. Например — разрешение циклических вложенностей блоков.
про нагрузку
Необходимо обеспечивать хорошую отзывчивость даже на больших документах и медленных компьютерах, потребляя при этом не слишком много памяти. Для этого приходится идти на кучу компромисов. И даже ГуглДокс, который синьоры пилят уже не один год, справляется этим не то, чтобы сильно хорошо.
про архитектуру REST вызовов
Это вообще ни о чём по сравнению с тем, что пользователь может выделить любую часть документа, содержащую любые части любых блоков, запустить любую команду, и это должно привести к адекватному результату.
Простой пример: если пользователь нажал B, то нужно пройтись по всем текстовым узлам и завернуть их в strong, кроме тех, что уже в strong. Но если все и так в strong, то нужно наоборот развернуть все strong.
А если пользователь нажал "завернуть в цитату", то нужно аккуратно разрезать блоки по краям выделения, завернуть содержимое в blockquote. А если нажал "развернуть цитату", то нужно найти все цитаты внутри выделения и развернуть их. Плюс разрезать цитаты, что пересекают выделение и развернуть соответствующие половинки. А если ни одной такой цитаты не нашлось, то найти ближайшую цитату, в которой находится выделение и развернуть её.
При этом любое разрезание/разворачивание должно сопровождаться слиянием соседних блоков. Например, если выделить текст с середины одного параграфа до середины другого и удалить содержимое, то параграфы должны склеиться. Но не любые блоки должны склеиваться. Например, ссылки склеиваются только если они ведут на один и тот же ресурс.
И это я вам сейчас приоткрыл лишь самый кончик айсберга. Можете сами представить какие проблемы будут при множественных выделениях, которые при этом могут ещё и пересекаться.
про синхронизацию между серверами и процессами; потоками,
Синхронизировать клиенты правки друг друг с другом должны не только надёжно, но и быстро, в реальном времени. И если есть возможность — часть работ выносится в отдельные веб-воркеры.
про парсинг
Пользователь может скопипастить в любую часть документа как плоский текст (мы ещё поддержали свой вариант маркдауна) так и весьма дикий html, который необходимо нормализовывать, ведь каждая IDE и каждый редактор документов выдаёт совсем разную вёрстку. Где-то строки разделяются br-ами, где-то заворачиваются в div-ы или p-шки, где-то и то и то. Про остальные типы блоков я даже не заикаюсь.
Для примера, из-за того что тег <picture/> это дикое позорище, а вовсе не, responsive image control, мне пришлось потратить неделю на написание своего, который по-настоящему responsive.
Что вы вкладываете в слово "responsive"?
В сложном UI обычная кнопка может вызывать неделю споров о том, как организовать его архитектуру, и две недели реализации (с многочисленными правками и переобуваниями в воздухе). Хотя с виду кажется, что там делать нечего, это же ведь обыкновенный <button/>, чего там обсуждать.
Что там в кнопке 2 недели реализовывать? Это на Реакте такая жуть?
Просто рынку и в самом деле сейчас не нужен сильный backend в таком количестве.
Когда рынку понадобится много "сильного" backend — он найдёт способ сделать и его тоже ужасно скучным. Потому что "скука" — это мера частоты, с которой некая задача встречается.
Плюс, у рынка не стоит задачи развлекать программистов (достаточно просто чтобы они к конкурентам не уходили).
Хотя я сам не сильно-то и люблю React, но всё же попробую ответить на некоторые придирки к нему.
«Где инъекции зависимости? Что ты имеешь в виду под „Не нужно никаких инъекций“? Вот пример: InversifyJS!»
https://habr.com/ru/company/docsvision/blog/350398/ (читать вместе с комментариями!)
«Функциональные компоненты»? Нет, нет, нет. Они нам не нравятся. Давайте работать с компонентами класса!"
Ну так работайте, в чём проблема-то?
«Почему эти функции просто болтаются в коде, и почему они не инкапсулируются внутри классов сервисов, чтобы сделать их статичными?»
Потому что нет совершенно никакого смысла заводить класс только ради статических функций если язык позволяет этого не делать.
Напомню, что в языках Java и C# глобальные функции запретили потому что там каждый файл с кодом "видит" все остальные, и без принудительного использования классов в качестве пространств имён получилась бы свалка. А в современном Javascript/Typescript используемые функции из других модулей импортируются явно.
Если же убрать из вопроса слово "статичными" — то ответ простой: ну а кто мешает их инкапсулировать при желании? Вот ни разу со мною не случалось такого, что я хотел что-то инкапсулировать — а фреймворк мне мешал!
«Где Retry Policy [прим. перев: политика повторения запросов] для API? Давайте реализуем её с помощью PollyJS».
Отлично, в вопросе уже содержится решение :-)
«Почему в именах файлов тире, когда имена классов – PascalCase? Имена файлов должны отражать имя класса в файле, поэтому отныне будем называть их SomePageComponent.tsx».
Переименовывайте, разрешаю :-)
А если серьёзно — то потому что в файле может быть не один класс.
И вопрос, который раздражает меня больше всего: «Как я могу запустить его в Visual Studio, а не в Visual Studio Code?»
Э-э-э, берём и запускаем?
Сборка фронта делается при помощи свойства PreBuildEvent или таргета с указанием AfterTargets="BeforeBuild". Хотя конкретно этот шаг я пропускал, потому что фронт собирается долго, и проще собирать его вручную чем каждый раз ждать когда он соберётся.
Далее прописывается .UseStaticFiles() с путём нужной папке и всё.
Напомню, что в языках Java и C# глобальные функции запретили потому что там каждый файл с кодом "видит" все остальные, и без принудительного использования классов в качестве пространств имён получилась бы свалка. А в современном Javascript/Typescript используемые функции из других модулей импортируются явно.
Да тоже могут получаться свалки, когда экспортируемые функции стекаются в index.ts, как "export * from ...", с возможными конфликтами имён и прочими радостями. Потому иногда группировать полезно.
Теперь про вторую пачку вопросов.
Какой маршрутизатор следует использовать?
Ну, WPF как-то обходится вообще без маршрутизатора. Поскольку речь идёт о корпоративном приложении — не думаю, что требуется его индексация поисковыми роботами, а значит можно поступить точно так же.
Если же маршрутизатор таки нужен (скажем, чтобы пользователи могли передавать друг другу ссылки или сохранять что-то в закладки) — то что, есть какие-то варианты кроме react-router?
Что кроме Redux мы должны использовать для асинхронных действий? Trunk? Saga?
А вот в формулировке этого вопроса уже содержится ошибка. Как уже упоминали в комментариях выше — для бывших WPF-разработчиков надо было выбирать mobx. Да, тут ошибка автора.
Должны ли мы использовать Axios или fetch API в браузере?
Swagger надо выбирать, swagger. Точнее, надо выбрать любой из OpenAPI-генераторов для кода клиента и забыть об этой проблеме.
Redux-Forms, Formiq или Final-Form?
Вот тут ничего не скажу, поскольку сам не до конца понимаю зачем оно вообще нужно.
Styled-Components, makeStyle, SASS или чистый CSS?
Чистый CSS — точно не вариант. А между остальными вариантами выбор должен был сделать автор, его для того в проект и приглашали же. И уж точно не WPF-разработчикам три недели спорить об этом.
А что с библиотекой интернационализации?
А корпоративному приложению она нужна?
Есть международных корпорации. Есть страны с несколькими языками.
что, есть какие-то варианты кроме react-router?
Но он ведь отвратительный настолько, насколько это возможно. Начиная с того, что почему-то вся его логика должна лежать в слое View.
Но ведь роутер — это, прежде всего, компонент управляющий отображением. Где ещё может лежать его логика?
Ну по такой логике весь код на клиенте управляет отображением и всё должно лежать во вьюшке))
Ну если брать клиентский код и грубо делить его на вью/модель, то, конечно, он должен лежать в модели, ведь "вью" — это скорее "как отображать", а "модель" — это "что отображать".
Он должен лежать в модели, ведь "место, где находится на данный момент пользователь" — это данные (которые, кстати, могут понадобиться в модели, а находятся они только во вьюшке)
Как только вы перенесёте роутер в модель — поймёте насколько глупой была идея делать роутинг во вьюшке.
А ещё в нём хреновая динамичность. Вот к примеру у меня роутинг статический. Выглядит, образно говоря, так:
type ArticleId = number;
class ArticleRoute {
constructor (public readonly id: ArticleId) {}
public url => $`/article/{id}`;
}В мобиксовый моделях я могу полить соответствующие роуты:
class ArticleModel {
public route => new ArticleRoute(this.id);
}Соответственно, когда я делаю рендер с ссылками — там всё строго типизировано и я не могу перекинуть на неправильную ссылку:
{articles.map(a => (
<Link to={a.route} />
)}А если роут поменяется — он поменяется сразу во всех местах, а надо пробегать строками по коду, где у меня есть ссылки на эти страницы.
Соответственно, когда я делаю рендер с ссылками — там всё строго типизировано и я не могу перекинуть на неправильную ссылку
На самом деле можете:
class FooModel {
public route => new BarRoute(this.id); // упс
}Да, вы правы. Но количество точек отказа существенно меньше и они не дублируются. То есть ошибка связи "объект -> роут" может быть только в одном месте — в модели. И достаточно обнаружить её на тестировании только в одном месте, чтобы пофиксить во всех.
В случае с вьюшечным реакт роутом эта ошибка связи может встретиться во ВСЕХ местах независимо, где есть ссылка на соответствующий роут.
есть какие-то варианты кроме react-router?
Конечно, написать свой используя mobx.
react-router говно и всегда им был.
Мораль истории: не так сложно смигрировать приложение с одной технологии на другую, как поменять мышление разработчиков на новые парадигмы
Это не решение для enterprisе и тем более не для ускорения разработки.
Любой проект с хуками вне tutorial превращается в нечитаемое спагетти. Нужны хорошие знания JavaScript и отличное абстрактное мышление, чтоб вообще знать и понимать когда и что там происходит и обновляется. Вместо декларации переменных громоздкий — useState, оборачивание всех if в useEffect. Во множестве случаев новички React нагромождают огромое количество ошибок даже не понимая этого, им кажется все простым. Для них загадка когда и почему идут обновления и сколько объектов создается при каждом рендере.
Множество проблем как сильное связывание кода, невозможность атомарно тестировать хуки, нет нормального dependency injection.
Недавно была статья-разъяснение useCallback. Это очень печально, что для базового кирпичика фреймворка нужны статьи чтоб объяснить базовые понятия.
Все должно быть понятно с первого взгяда, но этого к сожалению это не про React.
Другая парадигма предполагает другие правила хорошего тона. И задача архитектора задать их и донести до команды, особенно пришедшей с другого стэка.
Если что-то нужно доносить, это уже проблема.
Другая парадигма предполагает другие правила хорошего тона.
Правила хорошего тона сработают только если парадигма действительно рабочая, а если появляются всякие хуки, то это, мягко говоря, какая-то немного ущербная парадигма.
И задача архитектора задать их и донести до команды
Задача архитектора — это только спроектировать архитектуру приложения, на этом собственно все, никому и ничего он доносить не должен, этим евангелисты пусть занимаются. Более того, правила хорошего тона должны быть понятными, простыми и очевидными, ну а зрелая технология должна однозначно указывать что такое хорошо, а что такое плохо.
Ну самый простой пример, это один из самых ужаснейших антепаттерноа как множественное наследование. И такие древние языки программирования как C++ и Пухтон, которые рождались в муках когда ООП еще было просто прикольной концепцией и народ еще не успел шишок набить, страдали соответствующими врожденным изъяном — они допускали множественное наследование. Там, конечно, пытаются как-то побороть связанную с множественным наследованием неоднозначность, но в более современных ООП языках просто взяли и выпилили саму возможность иметь более одного базового класса, т.к. прием программирования от которого UB много больше чем пользы — это плохой прием. Джависту и дотнетчику не нужно объяснять, что единственный базовый класс является хорошим тоном, просто потому что ни Жаба, ни C# не дадут отнаследоваться более чем от одного :-)
Причем, дата создания языка понятное дело ничего не гарантирует. Например, вполне себе современный язык программирования Go не умеет в в такую хорошо известную с 70-ых годов вещь, как обобщенное программирование, все бы ничего, вот только Golang строго-типизированный язык. Понятное дело, что строгая статичная типизация без возможности обобщенного программирования — это очень серьезный косяк в дизайне, и никакие насаждаемые правила хорошого тона, рассусоливания про интерфейсы и философию уже не спасут от тонн копипасты и лапши — ну просто потому что прием программирования позволяющий писать красиво и эффективно банально недоступен by desgn. Но не прошло и 10 лет, как создатели Golang все же призадумались о дженериках (умная мысля приходит апосля, бывает) — хорохрились-хорохорились, прикрываясь мнимой простой, но в итоге сдались.
Из-за отсутствия множественного наследования получаются странные иерархии классов. Например, какой-нибудь EventEmitter появляется в корне дерева классов. Нельзя просто отказываться от множественного наследования, не предлагая ничего взамен.
Наследование в принципе оказалось неудачной концепцией с настоящими подводными валунами:
Во-первых, вызов переопределенных методов приводит к кэш-промаху, чем иерархия наследования глубже, тем больше будет кэш-промахов. А накладные расходы связанные с кэш-промахом могут быть достаточно ощутимые. Во всем, что связано с high perfomance computing наследование избегают.
Во-вторых, при очень глубоких иерархиях наследования появляется такой неприятный эффект как хрупкие базовые классы: пока Васян пилит свой свой класс, находящийся где-то на 10-ом уровне наследования, приходит Димон и что-то там фиксит на 2-ом уровне наследования, в итоге у всех наследников уровнями ниже меняется логика поведения, а Васян испытывает фрустрациии. В каждом крупном проекте видел такие ситуации. Иногда какой-нибудь незначительный фикс спустя год разработки приводит к тому, что приходиться перепиливать всю иерархию классов.
В-третьих, наследование немножко разрушает инкапсуляцую. Ну вот как-то так, класс-наследник является надмножеством базового класса, и включает в себя весь базовый класс, со всеми его приватными свистелками и перделками.
В-четвертых, много кто ошибочно верит, что наследование позволяет реализовать полиморфизм, однако ж, на самом деле наследование нифига не гарантирует поведенческий полиморфизм подтипов.
В общем наследование вещь опасная и требует очень осторожного подхода при проектировании архитектуры ПО, и даже большие и серьезные компании могут облажаться. Вот мой самый любимый пример — это стэк и очередь в Жабе. Вообще стэк и очередь — это достаточно примитивные структуры данных, в которые можно только поэлементно что-то пихать и также поэлементно опорожнять их, все, однако в Жабе поступили по другому — их сделали наследниками от списков, вот только списки и очереди это совершенно разные структуры данных, никак друг с другом не связанные, и при таком подходе к наследованию у стэка и очереди появляются нехарактерные для них свойства, ну, например, произвольный доступ. Т.е. однозначно вот это вот
https://docs.oracle.com/javase/7/docs/api/java/util/Stack.html
пример говнодизайна. Кто-то поторопился, не подумал как надо, и обратно уже не выпилишь, так и живем. Вроде бы работает, но сам факт того, что в самой Жабе встречаются примеры того как нельзя делать уже доставляет.
Так что лучше по возможности наследование все же избегать и заменять его композицией. Ну а для того, чтобы заранее отбить охоту наследоваться где попало, пришлось придумать запечатанные классы — это к слову о правилах хорошего: архитектору не нужно ходить и доносить до всех когда можно, а когда нельзя плодить наследников, вместо этого он просто запечатывает классы, что избавляет разработчиков от лишнего соблазна.
Кстати в Дотнете, который появился позже Джавы, со стэком и очередью так не опростоволосились
https://docs.microsoft.com/ru-ru/dotnet/api/system.collections.generic.stack-1
Но там тоже бывали свои приколы, как, например, на самой заре дотнета не было дженериков, зато была уйма неуниверсальных коллекций, которые до сих пор есть, но ими никто сейчас не пользуется и они уже давно стали атавизмом. Или еще более забавная ситуация, когда мелкомягким пришлось менять логику работы foreach — это уже не имеет прямого отношение к наследованию, это уже другая хипстерская штучка — функциональное программирование. Ну вот все любят ФП-сахар, но 90% любителей сахара отказалось не готово к такому явлению как замыкание, и все время напарывалось на одни и теже грабли.
Нельзя просто отказываться от множественного наследования, не предлагая ничего взамен.
Композиция же. Берем и собираем нужный набор компонентов в нужном контейнере и радуемся жизни.
Наследование это все же про переиспользование кода, а переиспользовать код можно по разному. Для полиморфизма же есть другие приемы: перегрузка, интерфейсы и обобщенное программирование.
Во-первых, вызов переопределенных методов приводит к кэш-промаху, чем иерархия наследования глубже, тем больше будет кэш-промахов.
Это свойство скорее полиморфизма и как следствие непрямого вызова. Если у вас нет полиморфизма в какой-то точке приложения, то там компилятор вполне в состоянии заинлайнить вызов конкретной функции. Не важно, используете вы наследование или нет.
пока Васян пилит свой свой класс, находящийся где-то на 10-ом уровне наследования, приходит Димон и что-то там фиксит на 2-ом уровне наследования, в итоге у всех наследников уровнями ниже меняется логика поведения, а Васян испытывает фрустрациии.
Это наблюдается с любым методом переиспользования общего кода. Единственный способ этого избежать — копипаста. Наследование тут ни при чём вообще.
наследование немножко разрушает инкапсуляцую. Ну вот как-то так, класс-наследник является надмножеством базового класса, и включает в себя весь базовый класс, со всеми его приватными свистелками и перделками.
К приватным свистелкам он доступа не имеет. Инкапсуляция никак не нарушается.
Вот мой самый любимый пример — это стэк и очередь в Жабе.
В Жабе много бестолковых дизайнерских решений. Боксинг, вариантность и тд. Не пинайте калеку, возьмите более вменяемые ООП языки. Ну, D, например. Там нет таких проблем.
архитектору не нужно ходить и доносить до всех когда можно, а когда нельзя плодить наследников, вместо этого он просто запечатывает классы, что избавляет разработчиков от лишнего соблазна.
А потом распечатывает, чтобы это можно было хоть как-то протестировать.
Композиция же. Берем и собираем нужный набор компонентов в нужном контейнере и радуемся жизни.
Это приводит к большому объёму бойлерплейта. А чем больше типового кода, тем больше в нём багов, больше потребеление памяти, меньше производительность программиста и самой программы, меньше скорость сборки.
Но на самом деле наследование — это и есть композиция с автоматическим делегированием. Плюс опциональные виртуальные методы. Больше отличий нет.
Вы мягко говоря неправы, композиция ничего не дублирует, вы все-равно выносите дубликаты в отдельные методы, которые к тому часто становятся без сайд эфектов и успешно их внедряете с DI.
"Но на самом деле наследование — это и есть композиция с автоматическим делегированием. "
О боже, конечно нет, вы упускаете ключевые различия. вы не можете независимо внедрить часть наследованной иерархии, код сильно связан и тестировать композицию намного проще, так как вы имеете независимые куски и нежно инициировать всю иерархию.
То что я написал очевидно после любого Энтерпрайз уровня проекта. Начните использовать шаблоны с композицией и вы убедитесь сами.
Вы мягко говоря неправы, композиция ничего не дублирует, вы все-равно выносите дубликаты в отдельные методы
Делегирование и прокидывание ссылок друг на друга особо некуда выносить.
вы не можете независимо внедрить часть наследованной иерархии
При множественном наследовании очень даже могу.
тестировать композицию намного проще, так как вы имеете независимые куски
А для тестирования эти независимые куски надо каждый раз собирать во что-то осмысленное.
То что я написал очевидно после любого Энтерпрайз уровня проекта. Начните использовать шаблоны с композицией и вы убедитесь сами.
Да-да, я вообще пороха не нюхал, только вчера курсы верстальщиков закончил.
А для тестирования эти независимые куски надо каждый раз собирать во что-то осмысленное.
Везде так, но с Dependency Injection сборка сервисов cтановится пустяком в отличии от наследования.
При множественном наследовании очень даже могу.
Да, кроме вершины и середины иерарихии.
только вчера курсы верстальщиков закончил
Что правда? Тогда ясно.
Рекомендую вам это почитать: https://github.com/nin-jin/slides/blob/master/testing
Узнаете немного нового от неудавшегося верстальщика.
Спасибо за грамотное развёрнутое объяснение.
Наследование на практике хуже чем композиция, не буду расписывать как автор выше, но это проверено на опыте и опробовано во множестве контекстов.
Наследование на практике другое чем композиция и они применяются в разных местах. Основные проблемы происходят когда применяется одно в момент, когда нужно было бы применить другое
Перефразируя вас: зрелая технология должна только работать без ошибок, а не кому-то что-то указывать (кроме пользовательских ошибок, нарушающих спецификации).
А обязанности архитектор на каждом проекте разные: от нарисовать на листочке несколько фигурок до разработки production ready нескольких модулей как пример и код-ревью каждого коммита на предмет соблюдения спроектированной архитектуры.
У хуков много недостатков, и смешение слоя работы с событиями, внутреннего состояния, асинхронных сайд-эффектов и синхронизации с DOM в одной функции — только одна из болей. Если опустить семантические, клубок зависимостей кастомных хуков и необходимость кеширования переменных и функций для их равенства по ссылкам, есть еще одна ключевая проблема — несовместимость с SSR, т.к. нет хука на componentWillMount, а значит сервер не сможет запустить фетчинг данных и дождаться его завершения. Согласен, что подход с хуками в энтерпрайзе — плохое решение, но с классами все достаточно прилично.
Если решили использовать новый подход, то будьте добры и старый код перевести на новый лад, плодить зоопарк себе же хуже.
Как и то, что одни разрабы делают в одном стиле, другие в другом, это неприемлемо в любом проекте, нужно добавлять линтеры на код стайл конкретного проекта, выделять время на тех долг
Не только в стилях, там и сам фрейморк пестрит проблемами.
Например, в Angular есть план миграции между версиями и поддержка CLI, в React это месяц ковыряния и хаков, чтоб старый код работал после апдейта. Например тима реакт пыталась взвалить это на свои плечи с их react scrip, но там критические вещи весят годами.
Я не придумываю и я бы не писал, если бы не столкнулся сам. Я использую только строгий Typescript и один из последних апдейтов react script просто повалил полностью проект при том, что именно react script должен взять на себя ответственность инкапсуляции настроек пакета и лёгких обновлений. Почитав ветки было очевидно, что Typescript темплейт они даже не тестировали. До этого нельзя было сделать из-за баги оверрайд настроек eslint и много других багов, например после обновления deprecated модули были еще включены...
По моему скромному мнению такой уровень качества недопустим. В этот же момент миграции Angular с 6 до 10 версии были абсолютно безболезненны с минорными изменениями и взамен давали производительность и уменьшение пакета и мне все-равно какая версия там eslint или tslint, это не должно стопорить работу команды на неделю.
Переводить не обязательно, но пометить как техдолг и выработать стратегию работы с ним типа "при любой задаче на изменение компонента переводим его на новый лад" надо.
Но опять же, можно выделять 20% времени спринта на исправление тех долга и доработке старых мест, если всегда рваться только вперед и никогда не оборачиваться на уже готовые части проекта, жди беды, рано или поздно, проект выйдет из под контроля.
я поизучал всё это и выбрал vue 3
Для вас очевиден один выбор. Для другого — другой. И лишь единицы могут свой выбор обосновать лучше, чем "ну этот мне попался первым, вроде норм".
Ну, судя по единодушно заминусованному моему комментарию выше и слитой практически в ноль карме, это нормальная ситуация, браться за технологические решения в больших проектах, не имея ни опыта, ни кругозора, и выбирая первые попавшиеся технологии. А я видимо отстал от жизни.
Может для автора выбор был очевиден, но он обсуждал варианты с командой, которая опыта точно не имела. Собственно основная его ошибка
У этой команды был опыт работы с более взрослыми технологиями. И нет ничего удивительного, что они хотели того же уровня поддерживаемости кода, а не как это принято в экосистеме Реакта.
Но выбрали в итоге редакс с сагами… А не, хотя бы, mobx
Очевидно, это был не выбор команды, а выбор того самого архитектора. Довольно бестолковый выбор. Просто глянул о чём статей больше пишут (а значит больше боли испытывают), то и выбрал.
Мне это не очевидно из поста
Ну что за привычка читать статьи по диагонали..
Как архитектор я создаю техническое предложение, которое содержит архитектурные детали, подход, план развития, руководящие принципы и, самое главное, технологический стек будущего приложения.
Для этого проекта я выбираю «React и Redux»… о чём буду жалеть два года спустя.
У этой команды был опыт работы с более взрослыми технологиями.
Это роли не играет, взрослые, не взрослые, играет роль наличие серого вещества, а там походу с этим всё плохо, раз взяли в пару с реактом — redux, а не mobx. Так что ничего удивительного, что всё плохо и убого.
Ведь при конфигурации react + tyescript + mobx всё в шоколаде.
Мобиксу этот ваш реакт с виртуальным домом — как собаке пятая нога. С нормальной реактивностью достаточно простого прямого рендерера в дом на пару килобайт и всё.
Для прямого рендера в DOM нужны нормальные шаблоны вместо JSX.
То есть любая нода без id у вас пересоздаётся на каждый рендер. Зашибись оптимизация, VDOM и то быстрее будет работать.
А ещё ваш код исходит из того, что список свойств никогда не меняется. То есть вот такой код будет работать не так как планировалось:
const props = some_cond ? { foo: 1 } : { bar: 2 };
const dom = <some_component id="some_id" {...props} />;То есть любая нода без id у вас пересоздаётся на каждый рендер.
Будет эксепшен. Можно даже заставить TS это проверять.
А ещё ваш код исходит из того, что список свойств никогда не меняется.
Менять список свойств — плохая идея в любом случае. Тут и низкая производительность полиморфного кода, и не удобство использования в реальном приложении.
Впрочем, это всё не важно, я вам показал принципиальную возможность — дальше вы сами.
Будет эксепшен. Можно даже заставить TS это проверять.
У вас такие ноды есть прямо в примере по той ссылке, которую вы дали.
Но даже если будет исключение — выходит не лучше. Присваивать id каждому элементу, вообще-то, несколько утомительно.
Впрочем, это всё не важно, я вам показал принципиальную возможность — дальше вы сами.
Вы показали принципиальную возможность написать какую-то неудобную фигню. Но удобной её не сделать, вот в чём проблема.
В контексте создания дерева идентификаторы не обязательны (основной кейс использования в моле), в контексте обновления документа обязательны.
Почему идентификаторы нужно не лениться ставить я объяснял тут: https://github.com/nin-jin/HabHub/issues/20
Мой выбор React hooks + Strict Typescript, RXJS, SCSS.
Может за это и любят, что "свобода"?
Так делают в netflix тоже, они не разобрались?
Именно. И им я тоже сочувствую.
Плюс какая разница Netfilx, Google или ещё что, работа в этих компаниях не делает тебя каким-то особенным или умнее остальных.
Более того, код который там пишут вообще не является тем, на что нужно ровняться. Тем более если вы следуете логике «Ну там наверное люди умнее работают, они лучше знают, поэтому и я так же буду делать».
Не многие могут похвастаться такими же результатами и очень большую часть вебсайтов просто выбрасывают в мусор практически сразу завершения разработки.
И этот выбор был сделан на основе анализа, а не из-за того что так делают в нетфликс.
Делает тебя умней по той причине, что сайт у них поддерживается большой коммандой много лет, доступен нон-стоп.
Сайт нетфликса довольно далёк от технической сложности и от какой-то особой масштабности. Ключевой компонент бизнеса нетфликса — видеоплеер — не имеет никакого отношения ни к реакту, ни к RxJS. Всё остальное, помимо видеоплеера — крайне не rocket science.
Делает тебя умней по той причине, что сайт у них поддерживается большой коммандой много лет, доступен нон-стоп.
Не многие могут похвастаться такими же результатами
И этот выбор был сделан на основе анализа, а не из-за того что так делают в нетфликс.
Оно и видно, что на основе анализа конечно же, долгого и кропотливого. Ни одного аргумента я не увидел.
Давайте реальные аргументы по которым связка React + RxJS уделывает React + MobX.
Всякие банальные вещи которые реализуются за 5-10 минут в случае надобности в виде Debunce, Reace conditions, отмены запросов можно не говорить, это не в счет, т.к. слишком простые задачи и 1 раз за карьеру реализовываются за считаные минуты и используются потом всегда и везде.
Может ваши аргументы будут убедительными и я тоже выберу RxJs вместо MobX.
Это не тема для комментария
А то получается как-то стремно всё же, вы сказали что провели целый анализ и осознанно сделали выбор. Но судя по вашим суждениям это пустые слова не имеющие ничего общего с правдой.
Вы же понимаете отнекиваться и пытаться отмазаться в простонародии называется *****больством и уважение к таким людям стремиться к нулю. Вы тут уже настрочили столько комментов мягко говоря не очень, так может хоть тут полезный коммент всё же оставите.
Вам все лишь нужно ответить на комментарий по нормальному, без отмазок habr.com/ru/company/skillfactory/blog/539068/#comment_22634000
Из этих пунктов ужасен только RXJS — вспоминаю с содроганием (но я вообще лютый ненавистник всякого ФП). Hooks, TS, SCSS, это нормальный выбор. На нынешнем проекте, правда, для стилизации используем styled-components, в целом удобны, но у них есть мерзкая проблема, когда надо закинуть имя класса в проп, который называется не className.
В Rx-библиотеках нет ничего плохого. Более того, они уже "исторически сложившиеся" и весьма неплохо работают — детские проблемы уже все давно отловили. Главная проблема использования Rx в проектировании интерфейсов — то, что библиотека даёт неудобные для интерфейсов абстракции. Хотя в интерфейсах всегда есть "события", которые легко заталкиваются в абстракции Rx, представлять вообще всю работу UI как обработку событий — тяжеловесно и очень плохо масштабируется.
«styled-components»
SonarQube с достаточно строгими правилами является корпоративным требованием. Стили в коде приводят линтер в ярость, но это не основная проблема. Есть проверенные годами язык CSS заменять его на JavaScript, мягко говоря, решение странное. Проблема инкапсуляции очень просто решается с SCSS.
Кроме того если прийдут новые молодые кадры с новым прекрасным фреймворком, то сss проще скопировать как минимум.
Надо было брать mobx, и всё было бы хорошо!
Стейт каждой странички должен быть вообще изолирован. Реюз между страничками — только через компоненты, и всякие хелперы в виде чистых функций.
Cтейт-менеджмент весь и работу с API лучше вообще спрятать от разработчиков конечных страничек.
В идеале, надо выделять отдельную core-команду, которая будет писать компоненты типа «страничка с таблицей и фильтрами», или «форма с валидацией», куда команды фичей могут только всякие метаданные да колбеки подсовывать.
Иначе будет полный раздрай, все себе напридумывают своих code style и фреймворков. А еще и через пошаренный через redux общий стейт будут регулярно ломать друг друга.
Core команда и отдельно что-то верстальщики простых компонентов? Где-то я уже такое слышал, а это же идеи Майкрософт 7 летней давности :). вот только в реакте оно все перемешано в одну кучу, как выносить бизнес логику?
создать папочку business-logic рядом с components и туда выносить?
И кто или что мешает выносить так? Сложности возникают, когда паттерн типа MVC ломают на основе "в реакт так не принято — в доках этого нет", не выделяя, прежде всего, слой модели (в широком смысле слова) в независимый от реакта. Формально он может и независим с тем же redux, но на практике перенести этот слой на тот же ангуляр не получится — проще заново написать.
Как меня чуть не уволили за выбор React для корпоративного приложения