На 51:10 Вы создаете task-row, который находится в entities и внутри него создаете ссылку в которой прописываете адрес для отображения details. У вас она простая (всего лишь /:id) и вопросов наверно не вызывает, но ведь ссылка на страницу details может быть другой и взята будет из слоя app из routing. Откуда слой entities знает какие ссылки есть в слое app? Вроде как нарушение методологии FSD?
Если я правильно понял описанную ситуацию, то мне кажется, что в таком случае ссылки лучше вынести в shared в константы и использовать их как в роутинге, так и в сущностях
Имхо, считаю что эта архитектура очень усложняет понимание проекта. Вместо того, чтобы пилить новую доработку, приходится часто думать о том, как декомпозировать компоненты. Очень повышается когнитивная нагрузка. Соответственно скорость написания фич падает. В команде используем модифицированный вариант, пришли к выводу, что в папку features лучше класть только реально переиспользуемые компоненты между разными страницами. А большинство компонентов держать по месту использования в папке страницы pages/[page-name] . Ну, а квери к примеру (для tanstack-query)/сторы или слой апи (rtk-query) можно держать чаще всего в папке entity.
А есть какие-то интересные масштабируемые стратегии переиспользования одного и того же(компонентов, например) и/или случаев, если отличается 1 иконка/кнопка/текст/блок для приложений уровня "Console AWS", "TH-cam" и т.д.?
@@mrakov ну по идее feature вполне переиспользуемые, карточка с разной иконкой может быть сущностью которая принимает какую то пропсу. Console aws вполне может быть собрана в виджете и переиспользоваться
Я считаю, что у тебя в разных местах что-то по чучуть отличается, например сегмент UI у тебя либо файл, либо папка. Хотя все должно быть стандартно ( в данном случае для UI - папка), чтобы была расширяемость. И чтобы не поишлось менять структуру проекта я считаю
Навигация по такому коду, где 80% файлов имеют имя index будет адом. Я часто использую поиск файла по имени и тут будет сложновато найти что надо, а когда проект станет больше то вообще нереально искать без помощи мышки
Я видимо не очень понял, как связана архитектура построения приложения, разбиение на сущности и взаимодействие различных слоёв с "давайте возьмём название папок, а писать будем как удобно нам, а там как пойдёт", если на первых страница описано, для чего папка "entity", что у неё есть слои, как раз под "api", что в "/shared/ui" не самое хорошее место класть архитектурный слой роутера, помимо простой "UI" компоновки, не говоря уже про "есть у нас todo-list, все элементы называется todo..., интерфейс также, а вот модель назову-ка я task, потому что могу". Попал на видео случайно, возможно это часть плейлиста с более детальным объяснением, но вне контекста информация только путает понимание, если оно было.
Видео предназначено для новичков чтоб на базовом уровне объяснить за что отвечает каждый слой и что это всего лишь набор правил из которых любое можно модифицировать пол себя и на любое можно забить)
@@webstack-frontend1697 но ведь прямо вначале мелькает фраза «мы возьмем только структуру папок», что уже вводит в заблуждение. Дело, конечно, каждого как «упрощать материал» для новичков, но, как мне кажется, это как «вот это - катана, для простоты будем называть ее ножом». В чем заключается упрощение путем полного изменения смысла на свой, при чем с частичной мутацией кор идей - мне не очень ясно. Есть отдельные тонкие моменты, где есть проблемы взаимоотношений слоев, которые в 1 время могут быть условно «виджетом» и «фичей» и как этого избегать, вот такие ситуации упомянуть или НЕ упомянуть, чтобы упростить - супер, окей. Но подмена понятий и замена смысла - звучит не как упрощение, как мне показалось. Но Ваш контент - Ваше дело.
Так же как вынесен mainLayout в видео, можно сделать authLayout внутри которого outlet и логика по проверке авторизации. И передать в него дочерние роуты, которые должны проверяться. Положить такой layout лучше в слой app
@@webstack-frontend1697 и вам хватает этого? Почему-то в архитектуре front'a все неявно и не четко) Нет конкретных рамок когда использовать components, pages, store, когда просто модульную архитектуру, а когда уже и на fsd логично замахнуться
зачем ты так сложно создаешь файлы? просто нажимаешь new file и пишешь путь "api/http-cinet/index.ts" и у тебя все создается. через new file можно даж папку создать "folder/" пишешь - косая черта на конце сделает это папкой :) пользуйтесь ))
![[#2024MAMA] G-DRAGON - 무제(Untitled, 2014)+POWER+HOME SWEET HOME+뱅뱅뱅+FANTASTIC BABY | Mnet 241123 방송](http://i.ytimg.com/vi/Ox29z5Nf1Uk/mqdefault.jpg)
На 51:10 Вы создаете task-row, который находится в entities и внутри него создаете ссылку в которой прописываете адрес для отображения details. У вас она простая (всего лишь /:id) и вопросов наверно не вызывает, но ведь ссылка на страницу details может быть другой и взята будет из слоя app из routing. Откуда слой entities знает какие ссылки есть в слое app? Вроде как нарушение методологии FSD?
Если я правильно понял описанную ситуацию, то мне кажется, что в таком случае ссылки лучше вынести в shared в константы и использовать их как в роутинге, так и в сущностях
единственный ютубер у которого стиль кода и стэк схож со мной ❤
Всё не мог понять, как entities с features объединять. Спасибо за наглядный пример!
@@pavelivanov3590 спасибо за поддержку!
Thank you for the video! I was looking for a real project with fsd applied and this was very helpful.
Thank you for support!
Имхо, считаю что эта архитектура очень усложняет понимание проекта. Вместо того, чтобы пилить новую доработку, приходится часто думать о том, как декомпозировать компоненты. Очень повышается когнитивная нагрузка. Соответственно скорость написания фич падает. В команде используем модифицированный вариант, пришли к выводу, что в папку features лучше класть только реально переиспользуемые компоненты между разными страницами. А большинство компонентов держать по месту использования в папке страницы pages/[page-name] . Ну, а квери к примеру (для tanstack-query)/сторы или слой апи (rtk-query) можно держать чаще всего в папке entity.
Fsd это как скрам. Чаще всего никто не использует его полностью, а берет только то что им удобно
А есть какие-то интересные масштабируемые стратегии переиспользования одного и того же(компонентов, например) и/или случаев, если отличается 1 иконка/кнопка/текст/блок для приложений уровня "Console AWS", "TH-cam" и т.д.?
@@mrakov ну по идее feature вполне переиспользуемые, карточка с разной иконкой может быть сущностью которая принимает какую то пропсу. Console aws вполне может быть собрана в виджете и переиспользоваться
@@webstack-frontend1697 fsd это кал который вам маркетологи продали
Очень подробно и классно рассказал. Продолжай в том же духе :)
Спасибо за поддержку!
Я считаю, что у тебя в разных местах что-то по чучуть отличается, например сегмент UI у тебя либо файл, либо папка. Хотя все должно быть стандартно ( в данном случае для UI - папка), чтобы была расширяемость. И чтобы не поишлось менять структуру проекта я считаю
Круто, от тебя объяснение FSD нужно обязательно посмотреть)
Только у тебя описание осталось с прошлого видео про effector, это так, мелочь
Ох, прошляпил. Спасибо что заметил, поправлю
А что за автокомплит кола у тебя в VSCode ?
А так все супер. Спасибо большое
Спасибо за отзыв! Вот видео про этот автокомплит
th-cam.com/video/8Hm5ygaYw0M/w-d-xo.htmlsi=-nSkxrD0pyYlMR5T
А если я хочу стили задавать css модулями, то куда класть эти name.module.css?
@@hmell7684 в слайсе может быть сегмент ui. Прям в него можно и класть
@@webstack-frontend1697 Спасибо!
Навигация по такому коду, где 80% файлов имеют имя index будет адом. Я часто использую поиск файла по имени и тут будет сложновато найти что надо, а когда проект станет больше то вообще нереально искать без помощи мышки
Я видимо не очень понял, как связана архитектура построения приложения, разбиение на сущности и взаимодействие различных слоёв с "давайте возьмём название папок, а писать будем как удобно нам, а там как пойдёт", если на первых страница описано, для чего папка "entity", что у неё есть слои, как раз под "api", что в "/shared/ui" не самое хорошее место класть архитектурный слой роутера, помимо простой "UI" компоновки, не говоря уже про "есть у нас todo-list, все элементы называется todo..., интерфейс также, а вот модель назову-ка я task, потому что могу". Попал на видео случайно, возможно это часть плейлиста с более детальным объяснением, но вне контекста информация только путает понимание, если оно было.
Видео предназначено для новичков чтоб на базовом уровне объяснить за что отвечает каждый слой и что это всего лишь набор правил из которых любое можно модифицировать пол себя и на любое можно забить)
@@webstack-frontend1697 но ведь прямо вначале мелькает фраза «мы возьмем только структуру папок», что уже вводит в заблуждение. Дело, конечно, каждого как «упрощать материал» для новичков, но, как мне кажется, это как «вот это - катана, для простоты будем называть ее ножом». В чем заключается упрощение путем полного изменения смысла на свой, при чем с частичной мутацией кор идей - мне не очень ясно. Есть отдельные тонкие моменты, где есть проблемы взаимоотношений слоев, которые в 1 время могут быть условно «виджетом» и «фичей» и как этого избегать, вот такие ситуации упомянуть или НЕ упомянуть, чтобы упростить - супер, окей. Но подмена понятий и замена смысла - звучит не как упрощение, как мне показалось. Но Ваш контент - Ваше дело.
@@mrakov ну значит это плохое видео ;)
Как раз обсуждение разницы структуры папок и подхода к проектированию th-cam.com/video/aD5Mst0OoSs/w-d-xo.html
Как настроить приватные роуты при такой организации роутинга?
Так же как вынесен mainLayout в видео, можно сделать authLayout внутри которого outlet и логика по проверке авторизации. И передать в него дочерние роуты, которые должны проверяться. Положить такой layout лучше в слой app
Добрый день. Почему используете win10?
Приветствую. Это мой домашний компьютер, на котором всегда стояла винда, для удобства поиграть в игры)
На нем удобнее всего записывать ролики
@@webstack-frontend1697 я к тому, что есть ли смысл вместо 11 поставить 10-ку?)
@@vit944 тут я не подскажу. Я ни разу не трогал 11
Я когда на 11 перешел - это была фатальная ошибка. Оставайтесь на 10-ке пока она не депрекейтед
@@flavkaa2017 а почему? можете по подробнее?
FSD - очень замороченная штука, а сложные вещи не выживают(native redux, saga и т.д.). Через 3 года о FSD никто и не вспомнит - скриньте!
Я сам до сих пор на 3х китах сижу. components pages и stores. Но насчет смерти я не согласен. На нем понапишут столько проектов что еще внукам хватит
@@webstack-frontend1697 и вам хватает этого? Почему-то в архитектуре front'a все неявно и не четко) Нет конкретных рамок когда использовать components, pages, store, когда просто модульную архитектуру, а когда уже и на fsd логично замахнуться
зачем ты так сложно создаешь файлы? просто нажимаешь new file и пишешь путь "api/http-cinet/index.ts" и у тебя все создается. через new file можно даж папку создать "folder/" пишешь - косая черта на конце сделает это папкой :) пользуйтесь ))
Спасибо за совет!
йерор
чето на мидловском языке)
Сейчас очень много проектов на этой архитектуре. Без ее знания сейчас и джуну будет тяжело)
@@webstack-frontend1697 это говорит лишь о снижение среднего уровня разработчиков)
@@webstack-frontend1697 тоже поначалу так думал. Потом понял, что ну такое себе и серебряной пули не существует
@@webstack-frontend1697 А джуну тяжело не будет, потому, что это не архитектура скорее, а структура папок