Столкнулся с особенностью применения useSyncExternalStore. Берем данные с помощью этого хука, а после вызываем действие внешнего хранилища, которое приводит к синхронному изменению состояния и тем самым сразу оповещает useSyncExternalStore. Будет ошибка рендера, типа нам нельзя менять внешнее состояние пока рендерится компонент. Как минимум нужно установку состояния вызывать в микротакске, например в Promise.resolve().then(...). А хук useSelector использует useState, чтобы заставить компонент рендериться после уведомления об изменении внешнего состояния. И это позволяет синхронно менять внешнее состояние. С другой стороны useSelector создаёт ошибки, если асинхронные действия внешнего хранилища интегрировать со Suspense (кидать промисы в исключения).
Нечитабельность вы своими руками делаете, если все вычисления прям в JSX пишите. Директивы шаблонов vue - вот достойный кандидат на звание абсолютной хрени :)
Селекторы на Reselect — лишний слой. Возник из-за бардака в структуре состояния. Имеем дело с "состоянием приложения", а не базой данных. Состояние нужно быстро, просто напрямую использовать без всяких трансформаций и заметаний следов к источнику. PS Саги для извращения логики. :)
redux можно приготовить без boilerplate-кода, без middleware (thunk, saga..) и вообще без кучи типов действий. Останется простой менеджер состояний без ваших минусов. То что вы сами изобретете, отказавшись от redux.
Естественную лень легко обойти, если "работу" держать перед глазами, ближе чем всякое потребительство. При включении компьютера вижу программный код — велики шансы сразу погрузиться в него и забыть про ютубы.
Запустить реальное клиентское приложение на сервере нереально сложно — куча граблей. Через webpack что только не подключают с особым извратом ) Самый простой случай с модульным css — игнорировать на сервере его import уже нельзя, в коде нужен объект с названиями css классов. Проще для сервера делать отдельную сборку по тому же конфигу webpack и её запускать. Статик и мета информация должна оказаться в <head>, и нужно определить, что именно вставить в соответствии с отрендеренной страницей. Рендер реакта не умеет это делать. Приложение в браузере спокойно может работать с глобальным контекстом (historyApi, sessionStorage, window...), оно уже изолировано браузером. На сервере же обработка запросов от множества клиентов, и если эта обработка асинхронная, то обязательно нужна изоляции рендеров от разных клиентов. Замыкания функцией express-роутера окажется недостаточным из-за природы клиентского приложения. SSR существенно влияет на архитектуру клиентского приложения, например в nextjs свои роутеры реализовали. А хотелось бы спокойно лепить фронт и при первой необходимости подключить SSR. В этом случаи headless браузера выглядит заманчивым. Рекомендую ещё посмотреть решение на воркерах и сбора статики через @loadable/component — там минимум вмешательства в клиентское приложение https://react-skeleton.ru/docs/develop/ssr/index.md.
Связанность создаёт свою проблему — поддержку целостности. При параллельном редактировании это ещё более сложно. Текстовый код всегда можно рассматривать источником истины. Структурные данные требуют многоуровневую систему поддержки. На СУБД посмотрите.
Какая стратегия то? Фактически применяете структурный редактор для написания структурного редактора. Замкнулись. Нет никаких козырей, чтобы зайти в область системного, веб программирования и др., где множество своих жестких особенностей.
Частенько сталкиваюсь с ситуацией, когда прекрасное решение не вписывается в контекст. Необходимо учитывать множество жестких условий. Автор планирует изменить условия (свой язык, git и прочая инфраструктура). Утопично. Шанс остается в узкой области, где сами условия способствуют выбору структурного редактора. Например, макрос для exsel описать, квесты на телефоне программировать без клавиатуры…
Столкнулся с особенностью применения useSyncExternalStore. Берем данные с помощью этого хука, а после вызываем действие внешнего хранилища, которое приводит к синхронному изменению состояния и тем самым сразу оповещает useSyncExternalStore. Будет ошибка рендера, типа нам нельзя менять внешнее состояние пока рендерится компонент. Как минимум нужно установку состояния вызывать в микротакске, например в Promise.resolve().then(...).
А хук useSelector использует useState, чтобы заставить компонент рендериться после уведомления об изменении внешнего состояния. И это позволяет синхронно менять внешнее состояние. С другой стороны useSelector создаёт ошибки, если асинхронные действия внешнего хранилища интегрировать со Suspense (кидать промисы в исключения).
Мне только не нравится, если все аргументы опциональные, то нужно передавать пустой объект
Нечитабельность вы своими руками делаете, если все вычисления прям в JSX пишите. Директивы шаблонов vue - вот достойный кандидат на звание абсолютной хрени :)
Вы не React улучшили, а создали нечто сомнительное. Ожидал какие-то предложения, которые вы хотите передать команде react
Не могу понять, что может вызывать неприязнь в JSX? Этож просто вызовы createElement в краткой форме
Ситуация с Dart напоминает ActionScript. И хотелось бы под Rust иметь Flutter
Мне какую-то хрень сгенерировала http://rudalle.ru/check_kandinsky2/9e4b4401796b456da845116784436e7f
Кажется так делает addobe fireworks
На сколько сложно или сколько часов потрачено на разработку текстового редактора (процессора)? Любопытно просто
Селекторы на Reselect — лишний слой. Возник из-за бардака в структуре состояния. Имеем дело с "состоянием приложения", а не базой данных. Состояние нужно быстро, просто напрямую использовать без всяких трансформаций и заметаний следов к источнику. PS Саги для извращения логики. :)
redux можно приготовить без boilerplate-кода, без middleware (thunk, saga..) и вообще без кучи типов действий. Останется простой менеджер состояний без ваших минусов. То что вы сами изобретете, отказавшись от redux.
Естественную лень легко обойти, если "работу" держать перед глазами, ближе чем всякое потребительство. При включении компьютера вижу программный код — велики шансы сразу погрузиться в него и забыть про ютубы.
Рейтинг у комментария требую :) оставить справа. Это привычно, удобней и главное — не создаёт визуального шума в переписке.
Без превью текстов постов — плохо.
Если не авторизован ещё, то ссылка на авторизацию в области комментов не работает.
Запустить реальное клиентское приложение на сервере нереально сложно — куча граблей. Через webpack что только не подключают с особым извратом ) Самый простой случай с модульным css — игнорировать на сервере его import уже нельзя, в коде нужен объект с названиями css классов. Проще для сервера делать отдельную сборку по тому же конфигу webpack и её запускать. Статик и мета информация должна оказаться в
<head>, и нужно определить, что именно вставить в соответствии с отрендеренной страницей. Рендер реакта не умеет это делать. Приложение в браузере спокойно может работать с глобальным контекстом (historyApi, sessionStorage, window...), оно уже изолировано браузером. На сервере же обработка запросов от множества клиентов, и если эта обработка асинхронная, то обязательно нужна изоляции рендеров от разных клиентов. Замыкания функцией express-роутера окажется недостаточным из-за природы клиентского приложения. SSR существенно влияет на архитектуру клиентского приложения, например в nextjs свои роутеры реализовали. А хотелось бы спокойно лепить фронт и при первой необходимости подключить SSR. В этом случаи headless браузера выглядит заманчивым. Рекомендую ещё посмотреть решение на воркерах и сбора статики через @loadable/component — там минимум вмешательства в клиентское приложение https://react-skeleton.ru/docs/develop/ssr/index.md.Связанность создаёт свою проблему — поддержку целостности. При параллельном редактировании это ещё более сложно. Текстовый код всегда можно рассматривать источником истины. Структурные данные требуют многоуровневую систему поддержки. На СУБД посмотрите.
Поясните в чем польза?
Какая стратегия то? Фактически применяете структурный редактор для написания структурного редактора. Замкнулись. Нет никаких козырей, чтобы зайти в область системного, веб программирования и др., где множество своих жестких особенностей.
Кстати, а где этот редактор сейчас планировалось использовать? Для каждой области у нас свои особые языки программирования. Незаменимые=)
Частенько сталкиваюсь с ситуацией, когда прекрасное решение не вписывается в контекст. Необходимо учитывать множество жестких условий. Автор планирует изменить условия (свой язык, git и прочая инфраструктура). Утопично. Шанс остается в узкой области, где сами условия способствуют выбору структурного редактора. Например, макрос для exsel описать, квесты на телефоне программировать без клавиатуры…