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