Я снимаю свой плащ и волшебную шляпу перед опенсорс комьюнити и не пытаюсь изобретать велосипед, но скорее «определить че делать» и «подобрать лучшие[из существующих] инструменты для решения конкретных задач».
Наличие в мейнстрими фреймворков, делающих из себя «one ring to rule them all» и совершенно не пытающихся ограничить область своего применения — причина появления этой статьи. Есть классные инструменты решающие конкретные задачи. (тот же мобикс, например, или rxjs). Давайте дружить с ними:)
Вопрос не «докопаться ради». Вы прочитали статью?
Мне интересно, поскольку если «да» и у вас возник этот вопрос — значит я плохо выражаю свои мысли и нужно исправляться.
Если «нет» — прочитайте если будет время после чего я открыт к обсуждению
Я абсолютно согласен с вами что фреймворки/либы — это мощное комьюнити и 100500 часов разработки, багофиксов и всего что скрывается за словом «мощное компьюнити».
Именно потому я не пытаюсь педалить свой велосипед с блекджеком и женщинами в части «реализации ответственностей» — все делается проверенными и поддерживаемыми инструментами.
Однако «определение» этих ответственностей, на мой взгляд, должно исходить из специфики приложения. Тесть из связки [Бизнес домен]+[Раздел 2, подраздер «ограничения» данной статьи]+[проверенные архитектурные принципы].
Соответственно, начиная работу над потенциально long-living приложением, разработчик обязан грамотно спроектировать структуру этого приложения и подобрать инструменты. Желательно — с возможностью замены этих инструментов.
Обратная ситуация: фейсбук переизобретает eventsourcing для фронта потому что NIH. Ден абрамов переизобретает elm на джаваскрипте, потому что талантливый гик который пробует клёвые идеи. Совпало, завертелось. 3-4 года значительная часть клиентов заказывают приложения на реакт-редакс потому что «фейсбук знает, так надо». Без анализа «а подойдёт ли это нам». 2020 год — интернет пестрит статьями «вай редакс зло» — хотя редакс совсем не зло а просто очень нишевая вещь, которая не была спозиционирована должным образом.
И вот написанный в реакт-редаксе код невероятно плотно забит приложение-специфическими вещами (миддлвары, разные типы екшнов, саги со своим синтакисом).
Бизнес логику просто невозможно «извлечь», а редакс уже «зло» и через несеколько лет из малого зла станет синдромом «легаси проекта».
Касательно онбординга в предложенном подходе:
Начинающий(или мидл) разработчик, прийдя на проект, услышит что у нас реакт+мобикс. И это будет абсолютной правдой. Относительно связки реакт+мобикс предложенная структура предлагает только лиш руководство к «месту где разработчик должен определять сторы», т.е. где в структуре компонентов (или вне структуры компонентов) эти сторы живут. И ирония в том что так или иначе работая с реакт-мобкс команде придётся такое решение делать.
Плюс к этому, подход запрещает использовать хуки (обьяснение в статье). Имея доступ к сторам, возможность использования хуков — это всего лиш способ делать одни и те же вещи двумя разными способами. Т.е. в контексте одного конкретного проекта — зло.
Однако я оставляю за собой возможность сменить реакт на преакт/инферно. Равно как возможность сменить мобкс на условный метеор. Why not?
Зависит от сложности фронтенда. Количество механик на современном фронте зачастую не даёт относится к нему исключительно как к вью слою. По последней цитате, все кроме абстрагирования от синтетических событий очень легко. А абстрагироваться от синтетических событий это и в самом деле написание нового фреймворка и делать этого, конечно же, не стоит.
Я полностью согласен с вами во втором утверждении и частично — в первом.
По второму — дырявая абстракция хуже отсутствия абстракции. Особенно когда в проектной документации и в презентациях новичкам «дырявость» изящно скрывается. Если дырка есть — о ней нужно кричать красным H1 заголовком — чего конечно же не любит менеджмент от слова «совсем».
По первому сложнее — если мы возьмем «идеальный фреймворк который полностью удовлетворяет нашим нуждам» — то да, абстрагирование от него безоговорочно замедлит разработку (сильно замедлит).
Но я не вижу в данный момент фреймворка который выглядел бы «о**нно» и мне бы хотелось его просто взять и спроксировать. Прочитайте PS статьи — сравнение подхода с работой в контексте популярных фреймворков. Буду рад подискутировать на этот счет.
Стоит ли возможность перенести приложение на новый фреймворк «потом» замедления разработки «сейчас»? It depends (tm)
Наличие в мейнстрими фреймворков, делающих из себя «one ring to rule them all» и совершенно не пытающихся ограничить область своего применения — причина появления этой статьи. Есть классные инструменты решающие конкретные задачи. (тот же мобикс, например, или rxjs). Давайте дружить с ними:)
Мне интересно, поскольку если «да» и у вас возник этот вопрос — значит я плохо выражаю свои мысли и нужно исправляться.
Если «нет» — прочитайте если будет время после чего я открыт к обсуждению
Именно потому я не пытаюсь педалить свой велосипед с блекджеком и женщинами в части «реализации ответственностей» — все делается проверенными и поддерживаемыми инструментами.
Однако «определение» этих ответственностей, на мой взгляд, должно исходить из специфики приложения. Тесть из связки [Бизнес домен]+[Раздел 2, подраздер «ограничения» данной статьи]+[проверенные архитектурные принципы].
Соответственно, начиная работу над потенциально long-living приложением, разработчик обязан грамотно спроектировать структуру этого приложения и подобрать инструменты. Желательно — с возможностью замены этих инструментов.
Обратная ситуация: фейсбук переизобретает eventsourcing для фронта потому что NIH. Ден абрамов переизобретает elm на джаваскрипте, потому что талантливый гик который пробует клёвые идеи. Совпало, завертелось. 3-4 года значительная часть клиентов заказывают приложения на реакт-редакс потому что «фейсбук знает, так надо». Без анализа «а подойдёт ли это нам». 2020 год — интернет пестрит статьями «вай редакс зло» — хотя редакс совсем не зло а просто очень нишевая вещь, которая не была спозиционирована должным образом.
И вот написанный в реакт-редаксе код невероятно плотно забит приложение-специфическими вещами (миддлвары, разные типы екшнов, саги со своим синтакисом).
Бизнес логику просто невозможно «извлечь», а редакс уже «зло» и через несеколько лет из малого зла станет синдромом «легаси проекта».
Касательно онбординга в предложенном подходе:
Начинающий(или мидл) разработчик, прийдя на проект, услышит что у нас реакт+мобикс. И это будет абсолютной правдой. Относительно связки реакт+мобикс предложенная структура предлагает только лиш руководство к «месту где разработчик должен определять сторы», т.е. где в структуре компонентов (или вне структуры компонентов) эти сторы живут. И ирония в том что так или иначе работая с реакт-мобкс команде придётся такое решение делать.
Плюс к этому, подход запрещает использовать хуки (обьяснение в статье). Имея доступ к сторам, возможность использования хуков — это всего лиш способ делать одни и те же вещи двумя разными способами. Т.е. в контексте одного конкретного проекта — зло.
Однако я оставляю за собой возможность сменить реакт на преакт/инферно. Равно как возможность сменить мобкс на условный метеор. Why not?
Я полностью согласен с вами во втором утверждении и частично — в первом.
По второму — дырявая абстракция хуже отсутствия абстракции. Особенно когда в проектной документации и в презентациях новичкам «дырявость» изящно скрывается. Если дырка есть — о ней нужно кричать красным H1 заголовком — чего конечно же не любит менеджмент от слова «совсем».
По первому сложнее — если мы возьмем «идеальный фреймворк который полностью удовлетворяет нашим нуждам» — то да, абстрагирование от него безоговорочно замедлит разработку (сильно замедлит).
Но я не вижу в данный момент фреймворка который выглядел бы «о**нно» и мне бы хотелось его просто взять и спроксировать. Прочитайте PS статьи — сравнение подхода с работой в контексте популярных фреймворков. Буду рад подискутировать на этот счет.
Стоит ли возможность перенести приложение на новый фреймворк «потом» замедления разработки «сейчас»? It depends (tm)