Причина, по которой стартапы “взлетают”, заключается в том, что люди работают как проклятые
А есть стартапы где не работают как проклятые но принимают правильные продуктовые решения и не тратят силы впустую. Сколько продуктов закрыла гугл до пандемии? Project Ara, Stadia, google+, Spark, Allo, Hangouts, Google Play Music, Nexus и Google One-линейки, Google glass. Список можно продолжать
Совет №1: старайтесь вести разработки именно в таком порядке — от сущностей до страниц. Не надо пихать весь код кучей в pages и потом пытаться это оптимизировать.
Это плохой совет. Оптимизировать структуру нужно там где это требуется. Если не знаете куда кидать компонент, лучше начинать с widget. Иначе будете тратить силы постоянно на размышления о том куда что запихать. FSD оч сильно тормозит скорость разработки если слишком запариваться, а профиты от декомпозиции со временем кажутся не такими очевидными.
/features в FSD по факту это недопапка. Потому что кроме экшен кнопок вы там вряд ли что либо будете хранить. Возьмём например крупную фичу которую бизнес решил добавить в приложение: визуальный редактор аватара пользователя. это фича или виджет?) для бизнеса это точно фича. Но пихать столько всего в папку фичи вы не будете. Тут идёт противоречие с бизнес моделью которое всех будет вводить в замешательство.
Ждать оперативного ответа на Email... Вы же прекрасно понимаете что email не работают если нужна оперативность. Идешь и пишешь коллеге в слак/телегу/любой мессенджер. Если совсем сложно, сразу ссылку на зум на 30 мин и вопрос решен. Зачем использовать устаревшие бюрократические инструменты? А потом удивления
Иногда кажется что люди не видят на рынке иных продуктов кроме тех что выпускает Apple..... AR/VR гарнитуры на рынке уже 10 лет. Вы только сейчас открываете для себя этот мир будучи дизайнерами. Не странно?
Компания Apple — отличный пример использования формы для создания уникального потребительского опыта. Их продукты упакованы в минималистичные, элегантные коробки с гладкими, округлыми формами, что подчёркивает премиальный характер продукции и вызывает чувство качества у потребителей.
А вы точно пользовались Vision Pro? Иначе бы не писали такое. Дизайн это не про визуал. Это в первую очередь про удобство. И вот как раз с этим у vision Pro проблемы, начиная с неправильной развесовки и внешнего аккумулятора , заканчивая непрактичным стеклом и бесполезным экраном спереди. Дизайн должен быть простым и соответствовать нуждам продукта. Поэтому пожалуйста, перестаньте видеть в дизайне лишь побрекушки и красотулички. Это не про это
Статья не очень по одной простой причине - не объясняется нормально синтаксис макросов. Нет примеров использования по каждому макросу в материале. Без всего этого статья для незнающего человека бесполезна. Вам может казаться что все просто и понятно, но для человека кто видит синтаксис впервые , увы, нет
Если у вас "сущность" принадлежит нескольким сущностям то это value object. И класть их в shared нормально. А вот sub entities и sub features я бы не использовал. Два новых слоя которые усложнят жизнь разрабам. Зачем?
Уже больше года работаю с FSD и могу сказать так, брать и полностью использовать его будет оверинженеринг. Нет смысла условную карточку товара делать частью entity и рендерить внутри кнопки-фичи через рендер пропсы. Это лишние действия которые на выходе дают почти всегда 0 профита.
Модельки стейта я почти всегда храню в entity и не размазываю их по виджетам просто чтобы иметь возможность использовать их на максимальном количестве слоев.
Вообще если даже просто взять и использовать структуру /entities, components, /pages, /shared, хранить в shared дизайн систему, в entities весь стейт и бизнес логику, в components реиспользуемые штуки типа кнопок-фичей, общих виджетов и модалок, а в pages хранить страницы внутри которых могут быть вложенные папки с виджетами то вообще никаких проблем не будет. Сохранится вся гибкость, не будет проблем с цикличными зависмостями ну и вы чётко будете видеть какие вмджеты используются на странице за счёт их вложенности в pages.
Короче говоря размазывание стейта по разным уровням повышает сложность, увеличивает риск цикличных зависимостей и на выходе лично мне особо не даёт профита, а разбиение на компоненты всего на свете тупо увеличивает время на разработку а на выходе профита не даст.
Ну и опять же. С FSD всегда будет вопрос - делать компонент виджетом или фичей? Вы будете сидеть и тупить вместо того чтобы идти и делать задачу. Как итог на выходе у вас папка с фичами будет состоять в основном из кнопок. Тогда почему папка называется features и в чем профит если можно точно так же кнопку сделать частью виджета? Реиспользуемость? Ну ну. Раз в полгода вам понадобится реюзать кнопку из фичи. Стоит ли оно того? Думаю что не стоит.
Ну а то что у вас на проекте были сложности до feature sliced, не означает что проблему нельзя было решить более простым вариантом разбиения ну и более грамотной работой с самой логикой приложения. Очевидно FSD не поможет писать более понятный код. FSD может дать иллюзию того что теперь у вас классная "архитектура", но на деле архитектура это не про папки, да и сложность работы с приложением только увеличится за счёт множества абстракции и постоянной проблемы - куда что класть
Как легко и просто дизайнеры отказываются от главной айдентики своего продукта. Щит с буквой Т это про что? Вселенная Marvel или антивирус? Бред. Редизайн должен сохранять главную идею логотипа, иначе в чем смысл редизайна? Новое лого без привязки к контексту любой студент нарисует.
Правда ребят, лучше не трогать ничего если не получается
“спрятали разбивку цены → не сработала, потому что пользователи хотели знать, из чего складывается цена;
“сократили блок с промокодом → не сработала, потому что пользователи не поняли, куда вводить промокод;”
Это же очевидные вещи. Любого чела спросить и он вам скажет что хочет видеть из чего складывается цена. Как вы проверяли гипотезу о том что людям это не важно?
Тоже самое с промокодом. Если делать поле «Промокод» в виде лейбла, очевидно чуваки не поймут, что это кликабельный элемент
Для тех, кто хочет что то быстро купить в интерфейсе можно сделать отдельную настройку укороченного чекаута. Чтобы удовлетворить потребности не только большинства , но и гиков которые тратят много и не хотят терять время на длинные чекауты. Это хоть и небольшой процент юзеров, но важный с точки зрения дороговизны покупок.
Это же не новая архитектура а улучшение существующей
А есть стартапы где не работают как проклятые но принимают правильные продуктовые решения и не тратят силы впустую. Сколько продуктов закрыла гугл до пандемии? Project Ara, Stadia, google+, Spark, Allo, Hangouts, Google Play Music, Nexus и Google One-линейки, Google glass. Список можно продолжать
Это плохой совет. Оптимизировать структуру нужно там где это требуется. Если не знаете куда кидать компонент, лучше начинать с widget. Иначе будете тратить силы постоянно на размышления о том куда что запихать. FSD оч сильно тормозит скорость разработки если слишком запариваться, а профиты от декомпозиции со временем кажутся не такими очевидными.
/features в FSD по факту это недопапка. Потому что кроме экшен кнопок вы там вряд ли что либо будете хранить. Возьмём например крупную фичу которую бизнес решил добавить в приложение: визуальный редактор аватара пользователя. это фича или виджет?) для бизнеса это точно фича. Но пихать столько всего в папку фичи вы не будете. Тут идёт противоречие с бизнес моделью которое всех будет вводить в замешательство.
Юзать транспилятор TS прямо в браузере откровенно говоря не лучшая идея. Минификация кода и treeshaking без сборщика? 😂
Зачем вы передергиваете, прекрасно понятно что имел ввиду автор поста
А где статистика? Или пост ради хайпа?
Ждать оперативного ответа на Email... Вы же прекрасно понимаете что email не работают если нужна оперативность. Идешь и пишешь коллеге в слак/телегу/любой мессенджер. Если совсем сложно, сразу ссылку на зум на 30 мин и вопрос решен. Зачем использовать устаревшие бюрократические инструменты? А потом удивления
Иногда кажется что люди не видят на рынке иных продуктов кроме тех что выпускает Apple..... AR/VR гарнитуры на рынке уже 10 лет. Вы только сейчас открываете для себя этот мир будучи дизайнерами. Не странно?
А вы точно пользовались Vision Pro? Иначе бы не писали такое. Дизайн это не про визуал. Это в первую очередь про удобство. И вот как раз с этим у vision Pro проблемы, начиная с неправильной развесовки и внешнего аккумулятора , заканчивая непрактичным стеклом и бесполезным экраном спереди. Дизайн должен быть простым и соответствовать нуждам продукта. Поэтому пожалуйста, перестаньте видеть в дизайне лишь побрекушки и красотулички. Это не про это
Хабр себя убивает такими useless публикациями
А давайте хабр не будет превращаться в клоунаду? 1 апреля не должно касаться публикаций . Что за фигня?
Статья не очень по одной простой причине - не объясняется нормально синтаксис макросов. Нет примеров использования по каждому макросу в материале. Без всего этого статья для незнающего человека бесполезна. Вам может казаться что все просто и понятно, но для человека кто видит синтаксис впервые , увы, нет
Если у вас "сущность" принадлежит нескольким сущностям то это value object. И класть их в shared нормально. А вот sub entities и sub features я бы не использовал. Два новых слоя которые усложнят жизнь разрабам. Зачем?
Уже больше года работаю с FSD и могу сказать так, брать и полностью использовать его будет оверинженеринг. Нет смысла условную карточку товара делать частью entity и рендерить внутри кнопки-фичи через рендер пропсы. Это лишние действия которые на выходе дают почти всегда 0 профита.
Модельки стейта я почти всегда храню в entity и не размазываю их по виджетам просто чтобы иметь возможность использовать их на максимальном количестве слоев.
Вообще если даже просто взять и использовать структуру /entities, components, /pages, /shared, хранить в shared дизайн систему, в entities весь стейт и бизнес логику, в components реиспользуемые штуки типа кнопок-фичей, общих виджетов и модалок, а в pages хранить страницы внутри которых могут быть вложенные папки с виджетами то вообще никаких проблем не будет. Сохранится вся гибкость, не будет проблем с цикличными зависмостями ну и вы чётко будете видеть какие вмджеты используются на странице за счёт их вложенности в pages.
Короче говоря размазывание стейта по разным уровням повышает сложность, увеличивает риск цикличных зависимостей и на выходе лично мне особо не даёт профита, а разбиение на компоненты всего на свете тупо увеличивает время на разработку а на выходе профита не даст.
Ну и опять же. С FSD всегда будет вопрос - делать компонент виджетом или фичей? Вы будете сидеть и тупить вместо того чтобы идти и делать задачу. Как итог на выходе у вас папка с фичами будет состоять в основном из кнопок. Тогда почему папка называется features и в чем профит если можно точно так же кнопку сделать частью виджета? Реиспользуемость? Ну ну. Раз в полгода вам понадобится реюзать кнопку из фичи. Стоит ли оно того? Думаю что не стоит.
Ну а то что у вас на проекте были сложности до feature sliced, не означает что проблему нельзя было решить более простым вариантом разбиения ну и более грамотной работой с самой логикой приложения. Очевидно FSD не поможет писать более понятный код. FSD может дать иллюзию того что теперь у вас классная "архитектура", но на деле архитектура это не про папки, да и сложность работы с приложением только увеличится за счёт множества абстракции и постоянной проблемы - куда что класть
Как легко и просто дизайнеры отказываются от главной айдентики своего продукта. Щит с буквой Т это про что? Вселенная Marvel или антивирус? Бред. Редизайн должен сохранять главную идею логотипа, иначе в чем смысл редизайна? Новое лого без привязки к контексту любой студент нарисует.
Правда ребят, лучше не трогать ничего если не получается
Зато сегодня все телефоны одинаково ужасны. Спасибо унификации но нет, я не хочу лопаты с корпусом в стиле женского маникюра и яркими оболочками.
Автор статьи явно не понимает как работают сейчас LLM. Архитектурно они не способны в процессе обучаться
На первый взгляд подход приятный. Спасибо
Хороший материал , спасибо
Это же очевидные вещи. Любого чела спросить и он вам скажет что хочет видеть из чего складывается цена. Как вы проверяли гипотезу о том что людям это не важно?
Тоже самое с промокодом. Если делать поле «Промокод» в виде лейбла, очевидно чуваки не поймут, что это кликабельный элемент
Для тех, кто хочет что то быстро купить в интерфейсе можно сделать отдельную настройку укороченного чекаута. Чтобы удовлетворить потребности не только большинства , но и гиков которые тратят много и не хотят терять время на длинные чекауты. Это хоть и небольшой процент юзеров, но важный с точки зрения дороговизны покупок.
На первый взгляд Svelte по DX теперь одна из вариаций React
Сколько лет проект делали? Дело не в спешке. Не было нормального тестирования вот и всё.