Или ваша фраза "мы можем привязать любую необходимую бизнес-логику" именно об этой возможности передавать разное значение для callback? )
Да, мы говорим именно об этой возможности. Я вижу так, что при необходимости мы можем создавать "слоты" для разных компонентов с экшнами, но это удобно, если наш интерфейс предполагает разные действия пользователя. Например, где-то кнопка, где-то инпут. Зачастую же это избыточно.
Именно поэтому мы и предлагаем наш подход. У FSD высокий порог вхождения, а также есть споры по поводу ее эффективности на дистанции, но сама идея создания общей договоренности о том, как строить проекты, абсолютно правильная. Говоря о классической архитектуре, каждый будет понимать свое и делать все по своему. И это не предположение, а личный опыт работы с командами. Насколько это проблема для ваших задач - решать вам. Мы же убедились в эффективности наличии общего фреймворка.
Также важно понимать, что те правила, которые мы предлагаем - это реакция на определенные боли с точки зрения Development Experience, с которыми мы сталкивались на протяжении многих лет работы, и которые с большой долей вероятности будут стрелять в "классической" архитектуре.
В нашем понимании это как раз шаг в сторону приятной и понятной разработки без лишнего, но с необходимым, чтобы не оказаться в ситуации, когда проект может поддерживать только сам его автор, либо это никому не нравится.
Я постарался подробно описать это в своей статье, но если что-то осталось непонятным - это можно спросить или прокомментировать.
Такой инструмент как стейт-менеджер предназначен для связи наших компонентов в разных частях интерфейса, чтобы не городить общие стейты на верхних уровнях. Это необязательно должно содержать в себе бизнес-логику, а в нашем случае вообще не должно.
Идея в том, чтобы инкапсулировать компоненты по тем зонам, к которым они относятся. По той же логике, условно, можно положить все компоненты приложения на один уровень /components. Но от этого мы и пытаемся уйти)
Это не всегда так. Иногда бывает, что фронтовая форма имеет только клиентские поля. Например галочка "Я принимаю условия...", которая служит для валидации. В таком случае типы будут различаться.
Это следующая проблема, о которой мы задумываемся, но пока что инструмента, который будет отвечать всем требованиям для нас мы не нашли. Возможно скоро мы это исправим)
В данном контексте архитектура - это определенный "фреймворк" того как мы организуем код в проекте. Это не только про структуру папок, но и про их содержание и связи.
Да, мы говорим именно об этой возможности. Я вижу так, что при необходимости мы можем создавать "слоты" для разных компонентов с экшнами, но это удобно, если наш интерфейс предполагает разные действия пользователя. Например, где-то кнопка, где-то инпут. Зачастую же это избыточно.
Именно поэтому мы и предлагаем наш подход. У FSD высокий порог вхождения, а также есть споры по поводу ее эффективности на дистанции, но сама идея создания общей договоренности о том, как строить проекты, абсолютно правильная. Говоря о классической архитектуре, каждый будет понимать свое и делать все по своему. И это не предположение, а личный опыт работы с командами. Насколько это проблема для ваших задач - решать вам. Мы же убедились в эффективности наличии общего фреймворка.
Также важно понимать, что те правила, которые мы предлагаем - это реакция на определенные боли с точки зрения Development Experience, с которыми мы сталкивались на протяжении многих лет работы, и которые с большой долей вероятности будут стрелять в "классической" архитектуре.
В нашем понимании это как раз шаг в сторону приятной и понятной разработки без лишнего, но с необходимым, чтобы не оказаться в ситуации, когда проект может поддерживать только сам его автор, либо это никому не нравится.
Я постарался подробно описать это в своей статье, но если что-то осталось непонятным - это можно спросить или прокомментировать.
Такой инструмент как стейт-менеджер предназначен для связи наших компонентов в разных частях интерфейса, чтобы не городить общие стейты на верхних уровнях. Это необязательно должно содержать в себе бизнес-логику, а в нашем случае вообще не должно.
Идея в том, чтобы инкапсулировать компоненты по тем зонам, к которым они относятся. По той же логике, условно, можно положить все компоненты приложения на один уровень /components. Но от этого мы и пытаемся уйти)
Это не всегда так. Иногда бывает, что фронтовая форма имеет только клиентские поля. Например галочка "Я принимаю условия...", которая служит для валидации. В таком случае типы будут различаться.
Это следующая проблема, о которой мы задумываемся, но пока что инструмента, который будет отвечать всем требованиям для нас мы не нашли. Возможно скоро мы это исправим)
В данном контексте архитектура - это определенный "фреймворк" того как мы организуем код в проекте. Это не только про структуру папок, но и про их содержание и связи.