Надо бороться с теми, кто вас давит, а не запрещать всех.
Запретами вы ничего не добьётесь. Более того, люди пернсядут на автобусы/авто, машин станет на дороге больше и статистика смертности от дтп не изменится в лучшую сторону.
Вот по поводу 2-го пункта - что значит при необходимости?
Мне кажется, он должен быть обернут by-default в useCallback, чтобы пользователи вообще не думали, когда используют его в зависимостях. И тут речь не об оптимизаци, а об удобстве использования библиотеки.
Просто если вы называете свою библиотеку лучшей, с самым большим количеством хуков для реакта (и дока действительно выглядит очень презентабельно), качество тоже должно как минимум соответствовать, иначе оно реально никому не нужно и будет плохо влиять на проекты. Нет смысла иметь сотню хухов, если они реализованы некачественно.
Люди, у которых на уме "запретить самокаты", обращаюсь к вам
Давайте представим, что проката самокатов больше нет. Вы думаете, это повлияет на статистику по несчастным случаям?
Думаем логически: люди начнут пересаживаться на общественный транспорт, такси и личный транспорт. Со временем транспорта станет больше. А если транспорта станет больше, то и несчастных случаев ТОЖЕ СТАНЕТ БОЛЬШЕ. И я практически уверен, что по итогу статистика останется +- той же, в рамках погрешности.
Поэтому не надо искать простые пути. Надо идти сложным путем и находить способы ограничения неадекватных катальцев и поощрять адекватных. Всем добра!
Но кстати, стейт-менеджер не обязательно может быть глобальным, тот же MobX может использоваться как локальный стейт. Скорее, стейт-менеджер - это система, позволяющая реализовывать слой вью-модели. То есть он занимается подготовкой данных для слоя отображения. Но, опять же, мнения могут быть разные.
Но это не говорит о том, что на этих инструментах нельзя полноценно писать. Можно, конечно, с использованием стандартных реакт-хуков и это будет полноценно.
Вообще, в идеале определиться с терминологией, а что вообще такое стейт-менеджер и что он должен уметь делать.
А в каком плане частичный? По типу, если элемента не видно, то вместо него отображается невидимая область нужного размера, и всё это автоматически происходит?
На картинке выглядит как будто просто линейный список, но в реальности всё, что угодно, может быть.
На самом деле не обязательно виртуальный скролл даже, можно же просто проверять, что виджет находится в пределах вью-порта и в зависимости от этого уже либо обновлять его данные, либо нет.
А в чем именно проблема использования внутренних инструментов для состояния? Понятно, что у MobX свои преимущества есть. Но адекватно можно и на том, и на другом писать.
Если на странице есть скролл, то надо делать просто виртуальный скролл и не отображать лишение виджеты. И всё, проблема решена, число элементов на странице не стремится к бесконечности
Камеры на каждом углу для чего?
Телеметрия на арендных самокатах для чего?
Регистрация через Госуслуги для чего?
Достаточно использовать эти инструменты во благо
Вы обобщаете сейчас
Надо бороться с теми, кто вас давит, а не запрещать всех.
Запретами вы ничего не добьётесь. Более того, люди пернсядут на автобусы/авто, машин станет на дороге больше и статистика смертности от дтп не изменится в лучшую сторону.
Либо строй инфраструктуру, либо не ной
Запретить проще всего
Этот человек мерит эффективность разработчиков по количеству строк кода, что вы ещё от него хотите
Чек предыдущей статьи
T9
Лидер просто поставить и не говорить всем, что лидеры не нужны
Ну это просто observable паттерн, базовый роутинг без плюшек, но прикольно, что так всё просто
Есть же Vue, ну можно даже с jsx использовать
Какой смысл альтернативы, если под него ничего не написано
Вот по поводу 2-го пункта - что значит при необходимости?
Мне кажется, он должен быть обернут by-default в useCallback, чтобы пользователи вообще не думали, когда используют его в зависимостях. И тут речь не об оптимизаци, а об удобстве использования библиотеки.
Просто если вы называете свою библиотеку лучшей, с самым большим количеством хуков для реакта (и дока действительно выглядит очень презентабельно), качество тоже должно как минимум соответствовать, иначе оно реально никому не нужно и будет плохо влиять на проекты. Нет смысла иметь сотню хухов, если они реализованы некачественно.
Люди, у которых на уме "запретить самокаты", обращаюсь к вам
Давайте представим, что проката самокатов больше нет. Вы думаете, это повлияет на статистику по несчастным случаям?
Думаем логически: люди начнут пересаживаться на общественный транспорт, такси и личный транспорт. Со временем транспорта станет больше. А если транспорта станет больше, то и несчастных случаев ТОЖЕ СТАНЕТ БОЛЬШЕ. И я практически уверен, что по итогу статистика останется +- той же, в рамках погрешности.
Поэтому не надо искать простые пути. Надо идти сложным путем и находить способы ограничения неадекватных катальцев и поощрять адекватных. Всем добра!
Ну, как сказать it блоггером, по делу у него роликов не было толком, насколько я помню
Возможно и так
Но кстати, стейт-менеджер не обязательно может быть глобальным, тот же MobX может использоваться как локальный стейт. Скорее, стейт-менеджер - это система, позволяющая реализовывать слой вью-модели. То есть он занимается подготовкой данных для слоя отображения. Но, опять же, мнения могут быть разные.
Получается, что так.
Но это не говорит о том, что на этих инструментах нельзя полноценно писать. Можно, конечно, с использованием стандартных реакт-хуков и это будет полноценно.
Вообще, в идеале определиться с терминологией, а что вообще такое стейт-менеджер и что он должен уметь делать.
Это всё-таки не совсем стейт-менеджер общего назначения так сказать
И какую же именно проблему решит стейт-менеджер?
Прикольно)
А в каком плане частичный? По типу, если элемента не видно, то вместо него отображается невидимая область нужного размера, и всё это автоматически происходит?
Сам думал о подобном как-то
Это да, всё от задачи зависит
На картинке выглядит как будто просто линейный список, но в реальности всё, что угодно, может быть.
На самом деле не обязательно виртуальный скролл даже, можно же просто проверять, что виджет находится в пределах вью-порта и в зависимости от этого уже либо обновлять его данные, либо нет.
А в чем именно проблема использования внутренних инструментов для состояния? Понятно, что у MobX свои преимущества есть. Но адекватно можно и на том, и на другом писать.
Именно! Я об этом ниже писал
Если на странице есть скролл, то надо делать просто виртуальный скролл и не отображать лишение виджеты. И всё, проблема решена, число элементов на странице не стремится к бесконечности