Сложно сказать, так как много чего неизвестно: какие данные в виджетах, как они загружаются (централизованно через сервер, или виджеты вообще сами по себе живут отдельно).
Насколько произвольными могут быть эти виджеты, что у них общее (как вижу, количество данных - общее).
И как понять, постоянно убираются/добавляются. В общем, как и всегда, нужно больше информации, чтобы можно было подумать над решением)
Зачем вообще так делать, не лучше просто сверху данные передавать?
Без всяких лишних useEffect-ов и useImperativeHandle
Данные наверху, отображение внизу. Данные о количестве уже имеются наверху, и никаких пропсов не нужно.
Если есть возможность написать без useEffect, значит нужно писать без useEffect, имхо.
Ещё эти cloneElement, children.map. На ровном месте проблемы себе создают, а потом их решают. С архитектурой явно что-то не то.
--------
Ну и самое важное: можно же не отображать данные, которые не видны на экране (вы говорите, что там скролл есть).
Соответственно, ваша архитектура уже не работает, т к у вас подписка на количество идёт из виджета (то есть скрыть не получается).
Это же самое простое, что можно сделать: просто не отображать, если не видно. Ну а данные вверху. Если данные рендерить не нужно, 90% проблем уходит сразу.
Ведь любое обучение происходит за счёт допущения ошибок и их исправления. А с нейронкой человек будет учиться не программированию, а написанию промптов. Так как ошибки исправлять он будет в поромптах, а не в коде
А я пришел к выводу, что генерировать текст лучше через ChatGPT, так как есть возможность нормально доработать текст там. Также, можно генерировать промпт для жанра
Именно! Оборачивать только, когда на то есть веская причина. Даже если кажется, что "операция дорогая, надо обернуть", если видимых проблем с перформансом нет, то не имеет смысла почти 100%
Вы можете дать конкретный пример большого проекта, сделанного по FSD? Чтобы было конкретно видно, в чем преимущества данной структуры папок. Чтобы мы говорили не о чем-то абстрактном, а по существу.
Что значит удобнее пере-использовать? Если вы положите компонент в папку components/, его нельзя будет пере-использовать?
С чего классическая архитектура менее масштабируемая? Может быть вы понимаете что-то другое под этим словом. Вам никто не запрещает создавать компоненты в компонентах, ну и так далее, в "классической" архитектуре.
В FSD, думаю, тоже. Но единственное - FSD добавляет свои ограничения, которые в огромном проекте будут только мешать и заставлять думать о том, о чем можно не думать при свободной организации кода. А также вообще непонятно, в чем преимущества такого подхода. Нельзя все проекты взять и подогнать под один шаблон.
Конечно, если на FSD писать ToDo-лист (а именно подобного уровня примеры я видел в официальной документации), всё может выглядеть красиво и по-фсд-шному.
В плане, что фронтендеру, как и бекендеру, придется разбираться с другими областями. Если он будет сам делать весь продукт, ему и дизайн понадобится, и маркетинг. Вообще, всё индивидуально ч конечно. Но однозначно, придется выходить за рамки своих компетенций
Так чем fsd-то хорош? Не масштабируемая штука абсолютно. А если что-то не масштабируется, толку от этого нет никакого, имхо. Вот есть у тебя папка фичей со слайсами. Она же будет бесконечно раздуваться по мере увеличения проекта из-за ограничений вложенности. (Да, я понимаю, что в сегментах может быть что угодно. Но зачем тогда оно вообще надо). Мне вот понравилась идея фрактальной структуры. Если какая-то часть проекта большая, там будет много папок и файлов. И всё это будет инкапсулировано в одном месте, а не разнесено по разным папкам.
Умение разложить задачу на структуры данных - это одно умение. Этим мы занимаемся каждый день при разработке.
Умение же перевернуть строку - это вещь в себе, которую мы не делаем каждый день, если вообще делали когда-то. В любом случае, это простая задача. Но: это абсолютно нормально не помнить все методы строки. Поэтому да, есть шанс, что не получится ее решить, если не загуглить
Есть инструмент - самокат. Есть пользователь инструмента - самокатчик.
Проблемы с инструментом я не вижу. Инструмент можно просто совершенствовать.
Проблема с самокатчикам. Не со всеми, а с маленьким процентом неадекватов. Процент маленький, но много пользователь * маленький процент = много неадекватов.
И решать этот вопрос надо не запретом всех и вся, адвумя вещами:
1) Вход по паспорту;
2) Индивидуальный подход к ограничениям. Самокат должен иметь системы, позволяющие анализировать поездки (камеры и так далее). Чтобы если вдруг произошел какой-то инцидент, относительно мгновенно бы последовали санкции.
Да, это сложная задача. Я всего лишь описал путь. И можно либо попытаться что-то сделать, либо сдаться и запретить всё и вся из-за недостатка мозга. Удачи)
А я не думаю, что стейт-менеджер тут на что-то влияет.
Что именно вы хотите решить, заменив useState на redux/MobX/ещё что-нибудь? Надо начать с первопричины.
Сложно сказать, так как много чего неизвестно: какие данные в виджетах, как они загружаются (централизованно через сервер, или виджеты вообще сами по себе живут отдельно).
Насколько произвольными могут быть эти виджеты, что у них общее (как вижу, количество данных - общее).
И как понять, постоянно убираются/добавляются. В общем, как и всегда, нужно больше информации, чтобы можно было подумать над решением)
Зачем вообще так делать, не лучше просто сверху данные передавать?
Без всяких лишних useEffect-ов и useImperativeHandle
Данные наверху, отображение внизу. Данные о количестве уже имеются наверху, и никаких пропсов не нужно.
Если есть возможность написать без useEffect, значит нужно писать без useEffect, имхо.
Ещё эти cloneElement, children.map. На ровном месте проблемы себе создают, а потом их решают. С архитектурой явно что-то не то.
--------
Ну и самое важное: можно же не отображать данные, которые не видны на экране (вы говорите, что там скролл есть).
Соответственно, ваша архитектура уже не работает, т к у вас подписка на количество идёт из виджета (то есть скрыть не получается).
Это же самое простое, что можно сделать: просто не отображать, если не видно. Ну а данные вверху. Если данные рендерить не нужно, 90% проблем уходит сразу.
Было дело)
Соглашусь
Ведь любое обучение происходит за счёт допущения ошибок и их исправления. А с нейронкой человек будет учиться не программированию, а написанию промптов. Так как ошибки исправлять он будет в поромптах, а не в коде
А я пришел к выводу, что генерировать текст лучше через ChatGPT, так как есть возможность нормально доработать текст там. Также, можно генерировать промпт для жанра
Именно! Оборачивать только, когда на то есть веская причина. Даже если кажется, что "операция дорогая, надо обернуть", если видимых проблем с перформансом нет, то не имеет смысла почти 100%
Как правильно подметил @clerik_r
Вы можете дать конкретный пример большого проекта, сделанного по FSD? Чтобы было конкретно видно, в чем преимущества данной структуры папок. Чтобы мы говорили не о чем-то абстрактном, а по существу.
Что значит оперировать бизнес-сущностями? Наличие папки "entities"? И как это поможет, если этих бизнес-сущностей тысячи
Про масштабирование и пере-использование я описал выше
Что значит удобнее пере-использовать? Если вы положите компонент в папку components/, его нельзя будет пере-использовать?
С чего классическая архитектура менее масштабируемая? Может быть вы понимаете что-то другое под этим словом. Вам никто не запрещает создавать компоненты в компонентах, ну и так далее, в "классической" архитектуре.
В FSD, думаю, тоже. Но единственное - FSD добавляет свои ограничения, которые в огромном проекте будут только мешать и заставлять думать о том, о чем можно не думать при свободной организации кода. А также вообще непонятно, в чем преимущества такого подхода. Нельзя все проекты взять и подогнать под один шаблон.
Конечно, если на FSD писать ToDo-лист (а именно подобного уровня примеры я видел в официальной документации), всё может выглядеть красиво и по-фсд-шному.
Мне кажется, это не так важно)
В плане, что фронтендеру, как и бекендеру, придется разбираться с другими областями. Если он будет сам делать весь продукт, ему и дизайн понадобится, и маркетинг. Вообще, всё индивидуально ч конечно. Но однозначно, придется выходить за рамки своих компетенций
Так чем fsd-то хорош? Не масштабируемая штука абсолютно. А если что-то не масштабируется, толку от этого нет никакого, имхо. Вот есть у тебя папка фичей со слайсами. Она же будет бесконечно раздуваться по мере увеличения проекта из-за ограничений вложенности. (Да, я понимаю, что в сегментах может быть что угодно. Но зачем тогда оно вообще надо). Мне вот понравилась идея фрактальной структуры. Если какая-то часть проекта большая, там будет много папок и файлов. И всё это будет инкапсулировано в одном месте, а не разнесено по разным папкам.
Если вникнуть ещё глубже, FSD может не понравиться
Зачем тащить 100500 селекторов? Почему смешивается логика и вью? Проблем не вижу, можно удобно распределить по необходимости
Я скорее про то, что одной вещью нельзя померить другую
Вот согласен.
Умение разложить задачу на структуры данных - это одно умение. Этим мы занимаемся каждый день при разработке.
Умение же перевернуть строку - это вещь в себе, которую мы не делаем каждый день, если вообще делали когда-то. В любом случае, это простая задача. Но: это абсолютно нормально не помнить все методы строки. Поэтому да, есть шанс, что не получится ее решить, если не загуглить
Тут согласен
Мне кажется, сравнивать должен профессиональный музыкант)
А у меня так, просто наблюдения)
Насчёт самой продвинутой, я бы поспорил
Есть ещё Udio, которая именно музыку (инструментал) лучше делает, как мне кажется.
Вы подменяете понятия.
Есть инструмент - самокат. Есть пользователь инструмента - самокатчик.
Проблемы с инструментом я не вижу. Инструмент можно просто совершенствовать.
Проблема с самокатчикам. Не со всеми, а с маленьким процентом неадекватов. Процент маленький, но много пользователь * маленький процент = много неадекватов.
И решать этот вопрос надо не запретом всех и вся, адвумя вещами:
1) Вход по паспорту;
2) Индивидуальный подход к ограничениям. Самокат должен иметь системы, позволяющие анализировать поездки (камеры и так далее). Чтобы если вдруг произошел какой-то инцидент, относительно мгновенно бы последовали санкции.
Да, это сложная задача. Я всего лишь описал путь. И можно либо попытаться что-то сделать, либо сдаться и запретить всё и вся из-за недостатка мозга. Удачи)