IR
Это не всегда удобно при расширении, когда одна маленькая фича "взрывается"
Если маленькая фича взрывается, то возможно это на самом деле две фичи
Что такое зашареный стейт в энтитес?
Чем энтити вцелом от фичи отличается?
Size: a a a
2021 March 10
IR
Менеджить состояние фичи можно только из самой фичи и только в её собственных целях.
Менеджить состояние сущности —напротив, можно также и из других абстракий кроме shared в целях этих абстракций
@sovasergey @ilya_azin поправьте, если что не так говорю
Менеджить состояние сущности —напротив, можно также и из других абстракий кроме shared в целях этих абстракций
@sovasergey @ilya_azin поправьте, если что не так говорю
IR
А раньше entities - это был shared, а UI/lib - наверху лежали
Нууу хз насколько проще)
Тут конечно и мы со своим видением пришли, суету навели
Но как никак мердж разных опытов
Нууу хз насколько проще)
Тут конечно и мы со своим видением пришли, суету навели
Но как никак мердж разных опытов
В том посте, кстати, entities до сих пор называются models ( капитан очевидность )
DS
Если маленькая фича взрывается, то возможно это на самом деле две фичи
Тогда как понять границы фичи и когда она нуждается в делении?
c
Тогда как понять границы фичи и когда она нуждается в делении?
Одна фича это одна полезная функциональность для пользователя
c
Когда ты в одной фича реализуешь несколько — это и есть нарушение границ
DS
Одна фича это одна полезная функциональность для пользователя
Одна полезная неделимая функциональность не может быть огромной по реализации?
c
Одна полезная неделимая функциональность не может быть огромной по реализации?
Может быть. Но это не плохо.
Плюс реализацию можно обобщить и унести из фичи в shared например
Плюс реализацию можно обобщить и унести из фичи в shared например
c
На основе одной и той же функциональности можно сделать очень много фич
DS
Может быть. Но это не плохо.
Плюс реализацию можно обобщить и унести из фичи в shared например
Плюс реализацию можно обобщить и унести из фичи в shared например
Я не говорю что это плохо. Изначальный вопрос был про то как организоваться код внутри такой огромной фичи
c
Не может быть фичи карта-офиса, а вот бронирование переговорки на карте, поиск сотрудника, смена рабочего места, да. Это уже три фичи основанные просто на карте офиса
c
И эти фичи маленькие
c
Как и код реализующий карту офиса
c
Я не говорю что это плохо. Изначальный вопрос был про то как организоваться код внутри такой огромной фичи
Смысл в том, чтобы в фиче лежал только код реализующий непосредственно саму функциональность, без лишних подробностей и всяких внутренних библиотек (в идеале)
c
Открываешь код фичи и видишь только то, что относится к задаче, не больше
DS
Открываешь код фичи и видишь только то, что относится к задаче, не больше
А если библиотека относится только к этой фиче?
DS
А че тут форматированый текст запрещен?
c
А че тут форматированый текст запрещен?
Такое нельзя запретить
DS
Такое нельзя запретить
Бот есть?
c
А если библиотека относится только к этой фиче?
Только ли к одной фиче? Может к сущности которой фича оперирует?
Вообще, можно создать внутри фичи lib
Вообще, можно создать внутри фичи lib