Да, вам нужно обмениваться данными между кодом, работающим в браузере, и кодом, работающим на сервере.
Основной подход заключается в использовании XHR. Клиент должен сделать что-то вроде этого:
(ns foo
(:require [goog.net.XhrIo :as xhr]))
(xhr/send "/api/names"
(fn [e]
(prn (.. e -target getResponseText))))
В качестве альтернативы есть очень широко используемая библиотека https://github.com/r0man/cljs-http.
(ns foo
(:require
[cljs.core.async :refer [<!]]
[cljs-http.client :as http])
(:require-macros
[cljs.core.async.macros :refer [go]]))
(go (let [response (<! (http/get "data.edn"))]
(prn (:status response))
(prn (:body response))))
Он использует core.async для возврата результатов вам по каналу. Вам действительно не нужно заботиться об этом, чтобы использовать его, за исключением того, что вещи в блоках go
произойдут «позже».
Для расширенного использования вы можете создавать веб-сокеты с помощью sente.
Одним из важных соображений, касающихся веб-страниц, является то, что они могут выполнять XHR только с тем же хостом на том же порту, который обслуживал страницу. Поэтому, если вы размещаете свой API на локальном хосте: 3030, то страница должна обслуживаться с локального хоста: 3030, чтобы вы могли с ней общаться. (Это называется одинаковой политикой происхождения).
В своем вопросе вы указали, что у вас есть API на порту 3000, а приложение Reagent обслуживается с 3030. Это не будет работать из-за той же политики происхождения. Существует стандарт под названием CORS Cross Origin Resource Sharing, который технически вы можете использовать, но на практике просто не делайте этого. Вместо этого обслуживайте HTML/Javascript с того же сервера, что и API.
Для вас это означает, что вам нужно быть уверенным, что при создании приложения Reagent HTML-страница, содержащая окончательный код JavaScript, должна обслуживаться тем же сервером, который обслуживает ваш API. Обычно это вопрос размещения HTML и JavaScript в папке ресурсов на сервере.
person
Timothy Pratley
schedule
06.02.2016