Реагировать на простой глобальный кэш сущностей вместо Flux / React / и т. Д. - PullRequest
Новая
       33

Реагировать на простой глобальный кэш сущностей вместо Flux / React / и т. Д.

0 голосов
/ 17 декабря 2018

Я пишу небольшой "забавный" проект Scala / Scala.js .

На моем сервере у меня есть объекты, на которые ссылаются uuid -s (внутри )Ref -s).

Ради "удовольствия" я не хочу использовать архитектуру Flux / Redux, но все же использую React на клиенте (с ScalaJS-React ).

Вместо этого я пытаюсь создать простой кэш, например:

  • , когда React UserDisplayComponent хочет отобразить Entity User с uuid=0003
  • затем метод render() вызывает Cache (который передается как prop)
  • давайте предположим, что это первый раз, когдаUserDisplayComponent запрашивает этот конкретный User (с uuid=0003), а у Cache его еще нет
  • , тогда Cache делает AjaxCall для извлечения User изсервер
  • когда AjaxCall возвращает триггеры Cache re-render
  • НО!теперь, когда компонент запрашивает User у Cache, он немедленно получает User Entity от Cache и не вызывает AjaxCall

.Я хотел бы реализовать это следующим образом:

  • Я запускаю render()
  • "вещи" внутри render(), запрашивая Cache для всех видов Entities
  • Cache возвращает либо Loading, либо сам Entity.
  • в конце рендеринга Cache отправляет все AjaxRequest на сервер и ждетчтобы все они вернули
  • после того, как все AjaxRequests вернулись (предположим, что они это делают - для простоты) Cache вызывает "re-render()", и теперь все сущности, которые былиCache сразу же предоставляют запрошенные ранее.
  • конечно, может случиться так, что вновь прибывшие Entity -ы вызовут render(), чтобы получить больше Entity -с, если, например, язагрузить Entity, например, тип case class UserList(ul: List[Ref[User]]).Но давайте сейчас не будем об этом беспокоиться.

ВОПРОСЫ:

1) Я делаю что-то действительно неправильно, если я делаю обработку состояния таким образом?

2) Есть ли уже существующее решение для этого?

Я огляделся, но все было FLUX / REDUX и т. Д. ... по этим направлениям ... - которые я хочу ИЗБЕГАТЬ ради:

  • "веселья"
  • любопытство
  • исследование
  • игра вокруг
  • Я думаю, что этот простой кэш будет проще для моего варианта использования, потому что я хочу взять "REF" на основе "Модель предметной области "передается клиенту простым способом: как если бы клиент находился на сервере, а сеть работала бы бесконечно быстро и с нулевой задержкой (это то, что должен имитировать кэш).

1 Ответ

0 голосов
/ 18 декабря 2018

Подумайте, какие проблемы необходимо решить для создания многофункционального динамического веб-интерфейса, и какие библиотеки / слои обычно решают эти проблемы за вас.

1.События DOM (щелчки и т. Д.) Должны вызывать изменения в состоянии

Это относительно просто.Узлы DOM предоставляют API слушателя на основе обратного вызова, который легко адаптировать к любой архитектуре.

2.Изменения в State должны инициировать обновления для узлов DOM

Это сложнее, потому что это нужно сделать эффективно и поддерживаемым способом .Вы не хотите перерисовывать весь ваш компонент с нуля всякий раз, когда изменяется его состояние, и вы не хотите писать тонны спагетти-кода в стиле jquery, чтобы вручную обновлять DOM, поскольку это было бы слишком подвержено ошибкам, даже если оно эффективно привремя выполнения.

Эта проблема в основном из-за того, что существуют такие библиотеки, как React, которые абстрагируются от виртуального DOM.Но вы также можете абстрагироваться без виртуального DOM, как это делает моя собственная библиотека Laminar .

Отказ от решения этой проблемы с помощью библиотеки работает только для более простых приложений.

3.Компоненты должны иметь возможность чтения / записи Global State

Это та часть, которую решает Flux / Redux.В частности, это проблемы №1 и №2, за исключением случаев, когда они применяются к глобальному состоянию, а не к состоянию компонента.

4.Кэширование

Кэширование затруднено, поскольку в какой-то момент кэш должен быть признан недействительным , помимо всего прочего выше.

Flux / redux не помогают с этимсовсем.Одна из библиотек, которая действительно помогает, - это Relay , которая работает так же, как ваше предлагаемое решение, за исключением более сложной и в дополнение к React и GraphQL.Чтение его документации поможет вам в вашей проблеме.Вы определенно можете реализовать небольшое подмножество функций реле в простом Scala.js, если вам не нужен весь багаж React / GraphQL, но вам необходимо знать предшествующий уровень техники.

5.Сериализация и безопасность типов

Это проблема only в этом списке, которая относится к Scala.js, в отличие от Javascript и SPA в целом.

Объекты Scalaнужно сериализовать, чтобы путешествовать по сети.В JSON, protobufs или что-то еще, но вам нужна система для этого, которая не будет включать подверженную ошибкам ручную работу.Существует множество библиотек Scala.js, которые решают эту проблему, таких как upickle, Autowire, конечные точки, ленивцы и т. Д. Ключевые слова: «Библиотека Scala JSON» или « Scala-безопасный RPC », в зависимости от того, чтоКакое решение вы хотите.

Я надеюсь, что эти принципы достаточны как ответ.Когда вы понимаете эти проблемы, должно быть очевидно, будет ли ваше решение работать для данного варианта использования или нет.На самом деле вы не описали, как ваше решение решает проблемы 2, 4 и 5. Вы можете использовать некоторые из упомянутых мной библиотек или реализовать собственные решения с похожими идеями / алгоритмами.

На небольшом техническом примечании рассмотрите возможность реализации асинхронного API на основе будущего для своего уровня кэша, чтобы он возвращал Future[Entity] вместо Loading | Entity.

...