If you generate CSS strings on the frontend, I think you have to explicitly create a <script> tag dynamically with the desired content and add it to the body. If you generate CSS strings on the backend, you can include them in your HTML, however you serve it. Or you can just cache it and serve as a CSS file.

shadow-cljs doesn't deal with CSS in any way.

I'm quite new at this, but bumped up against this recently. The way I solved it was just using plain scss files and have a yarn build:sass script in my package.json that runs something like: yarn sass --load-path node_modules/ sass/main.scss:resources/public/css/main.css Now, in the html file (resources/html, for me) I added the following line somewhere: {% style "/css/main.css" %} Et voila! I don't know about Garden, but presumably it has the equivalent of the sass command somewhere to generate the css. Hope that helps!

With Garden, the process would be similar iff you have static CSS. If you need to generate some particular CSS during the runtime, you cannot use such approach. All in all, depends on what OP needs, yeah.

Thanks a bunch for the input guys, will try to figure out something

@UR71VR71S We're using lein-jsass and it's working well.

Oo, that does look good. Thanks @U0HJJF9A4!

If you want to just embed some static data that's available during compilation, I would just write a Clojure macro.

I’m very new to clojure. What would that look like, and what’s the advantage of doing it that way? I ended up just doing (def myJson (js/require "../path/to/my.json")) which seems to work just fine for loading it as a js object

Ah, so your platform is Node.js? At least to my knowledge, that's the only place where js/require works.

If so, using js/require is completely fine.

require is usable on almost all JS platforms these days. It isn’t implemented in the browsers but almost all js apps are built using bundlers these days which do support import/require and many other features which are compiled down to browser compatible code. In this case I’m using react-native.

To be honest, I don't know that much about ES5-style, ES6-style, CommonJS-style imports/requires. Although I would argue that a bundler is not a part of a platform. It can do whatever it wants. In your case, since it works just fine, I would say that using it is just fine as well.

Out of curiosity, what would using a macro look like? I don’t understand clojure macros well enough to understand why they would be useful for static data.

Macro expansion is done in Clojure, the expanded code is the ClojureScript code, that is then transpiled into JavaScript for the target platform. Suppose my target platform is browser. Ideally, I want to supply a single JS file that has all of the required information needed to for the app to start. Suppose, that JSON must be part of this information. I would then write a macro that looks something like this, I suppose (not tested):

(defmacro static-json [path]
  (core/list 'js* (slurp path)))

(let [data (static-json "path/to/data.json")]
  (do-something-with data))

I've done something like this to turn e.g. a static SVG into a Hiccup data simply because I needed to manipulate it before displaying it.

I assume that's because none of the dev tools actually check for CORS. I don't think there's any reasonable way to make it work in a browser without changing the relevant headers on the server.

It's weird because I believe that JavaScripts fetch will get a response but some reason xhrio doesn't like this endpoint / server configuration for those endpoints?

Seems to me the fecth API works just as expected WRT CORS:

How did you check it?

I think because fetch can set headers xhrio can't?

NBA.js works for NBA endpoints essentially but for some reason I can't replicate the same in cljs

Maybe fetch can do that. But it cannot set Origin, and that is what matters.

Do you run NBA.js in Node?

And your ClojureScript code in a browser?

Yes I ran NBA.js in node

Yes in the browser

But in the Dev tools as well when I resend the request with the same headers that the original xhr request uses it returns a correct response, I don't understand why

Can you paste the exact code that you use in dev tools?

Unfortunately not right now but perhaps later

For instance in the network tab, I see a given xhr request that my cljs has, if I press (resend request) it'll work?

I need at least some code to be able to say anything useful.

(ns ^:figwheel-hooks tylerherro-io.core
  (:require
   [goog.dom :as gdom]
   [httpurr.client :as http]
   [httpurr.client.xhr :refer [client]]
   [promesa.core :as p]
   [reagent.core :as reagent :refer [atom]]))

(def stat-req-p (http/send! client
                            {:method :get
                             :url ""
                             :headers {}
                             }))

And what was the code that worked for you in the dev tools?

Because running a plain fetch on this URL doesn't work for me because of CORS, just as expected.

I'll just double check, one moment 😄

So in Firefox under the network tab essentially I can look at my xhr requests and resend them.

Host: 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Origin: 
Connection: keep-alive
Referer: 
Pragma: no-cache

these are the headers

Well OK, you did send out the request. But were you able to get the response and access it?

@U2FRKM4TW only after a resend via the dev tools, the request made by my cljs app returns nothing essentially

Also, replaying a network request != sending it from code.

I know

I know firefox must be doing something internally that doesn't mirror what CLJS is doing

perhaps it's sending with a different origin?

Can you send me a screenshot that contains the response that you see in the dev tools?

the valid response?

Yes.

Heh, I can't check anything right now because the URL has completely stopped working for me - it just hangs here and time outs.

yeah, without headers etc it'll just hang

idk why

it's very weird lol

tbh the NBA api in general is just tough to work with, I just wanted a toy problem to learn some CLJS haha

I thought when my app would start it'd just do a GET to a given API and display the data nicely basically

but I guess maybe a given client can't do this, I don't know. I don't know the different between say a client running code and a general browser request

My current guess is that you can view the response in Firefox, but you cannot actually use it in the code. The browser just won't let you because of CORS. NodeJS doesn't enforce CORS, that's why requests work there.

Ahh..

gotcha

because Node is a server-side language? or is it arbitrary?

I guess maybe clojure itself can make the request but not CLJS perse?

or does clojure enforce it as well (CORS)?

Because it's server side, yeah. CLJS is a language, not a platform. You can have a CLJS app that runs on Node for example.

@U2FRKM4TW via shadow-cljs? (CLJS on Node)

and yh, that's true

but say for example, cljs aside, I wanted to write a given clojure api that needed to make a GET request, would that have CORS?

I know it's kinda backwards but couldn't I myself have a given endpoint that just goes to that other endpoint with CORS ignored?

I'm being a bit dishonest here. De facto it's the platform that matters. But nothing prevents a particular language having a CORS check in its standard library (although, you would still be able to just not use the library and issue requests some other way).

@U2FRKM4TW gotcha, so in theory I could use some low-level stuff to form a XHR request without a CORS check?

You could use shadow-cljs for that, sure. Although I don't think it's necessary. You can make any requests from Clojure! So yeah, you can write an endpoint that proxies your requests just to deal with CORS. I'm not sure about low level stuff in browser. I think it would work only if you can open raw socket connections from browser, and I don't think you can.

@U2FRKM4TW nice, I guess the proxy endpoint would be the way to go then!

sounds like fun!

@U2FRKM4TW what's a nice way to go about writing a clj API, the ring library?

It's the default choice for many, yeah. But if you want to just test your CLJS code, you just need to proxy a request, replace some request headers, and remove a bunch of response headers - you don't need CLJ for this. There should be plenty of already written tools for this. It's fine if you just want to play around with CLJ and learn a bit though.

@U2FRKM4TW which tools? I tried modifying headers but somehow google's xhrio library is used by most http libs?

This, for example: https://github.com/Rob--W/cors-anywhere/

You could probably use raw Apache or NGINX.

@U2FRKM4TW nice

@U2FRKM4TW can I use JS libraries in cljs?

Sure! Consider using shadow-cljs for this since it makes it much easier, especially if you need NPM.

so I've decided to use shadow-cljs but where exactly would I write javascript or can I somehow interop with javascript in cljs?

Even when I proxy it through cors-anywhere I get "Missing required request header. Must specify one of: origin,x-requested-with"

when I try to set origin it says I cannot set a forbidden header

You cannot do it from the browser alone. You have to use some sort of proxy. cors-anywhere doesn't work probably because the server requires additional headers. Although it's strange that it doesn't detect Origin because it should be the one responsible for CORS as well. Have you tried setting x-requested-with manually? shadow-cljs will not help you with CORS in any way. It's just a build tool. But it's a good one and it makes JS interop much more simpler and robust, especially when you use NPM libraries.

yes I tried x-requested-with but I guess https://funcool.github.io/httpurr/latest/ doesn't allow me to set it

You're trying to solve a problem by changing multiple things at once. Try just using raw JS.

yeah I think I should yh

raw JS with fetch?

fetch or XMLHttpRequest.

gotcha

fetch cannot set a origin header for a request?

As I said - try the other header.

You cannot set Origin within a browser.

for some reason fetch form a OPTIONS request

but if I resend in the browser with GET as the method I get a valid JSON response

OK, let me re-highlight. 🙂 You cannot set Origin.

The browser can.

But you don't care, because you cannot use it.

I'm not setting Origin

I know.

The browser sets it.

oops, I forgot to delete Origin from my fetch request fields lol, one sec

You also don't set cookie yourself, for example.

async function getData(url = '', data = {}) {
  // Default options are marked with *
  const response = await fetch(url, {
    method: 'GET', // *GET, POST, PUT, DELETE, etc.
    mode: 'cors', // no-cors, *cors, same-origin
    cache: 'no-cache', // *default, no-cache, reload, force-cache, only-if-cached
    credentials: 'omit', // include, *same-origin, omit
    headers: {
      'Content-Type': 'application/json',
      'x-requested-with': 'XMLHttpRequest'
    },
    redirect: 'follow', // manual, *follow, error
    referrer: '' // no-referrer, *client
  });
  return await response.json(); // parses JSON response into native JavaScript objects
      }
      getData("")

If you dispatch a request from some backend platform, likely it won't be in your way and will just send the request as is. Meaning, it will add only the stuff you ask it to add. If you dispatch a request from a not horribly outdated browser, it will do all sorts of stuff for you. Set origin, set cookies, check CORS etc.

oh I understand

damn HTTP is real complicated lol, so many layers

but I did read in MDN that it'll do a preflight OPTIONS request sometimes

I guess because it's cross-origin? I don't know

Ha! That's not even scratching the surface.

I guess I should try to make the request from a backend then..

uh oh, there's more!

crazy stuff..

It's like this technology is vastly important and useful and has been around for ages or something. 🙂

haha

but I guess it's the browser that makes it complicated

not the protocol perse?

I don't mind the complexity as long as it's tractable or can be abstracted nicely

HTTP protocol has not been of interest in this discussion at all. CORS is a mechanism on top of HTTP. Browsers just follow the rules to implement CORS.

oh ok

MDN is your friend. Usually they have really nice documentation.

why is it that a server can set headers explicitly but not a client?

For security reasons. You can use a random website that can be malicious. You usually don't use a random server.

Okay, that makes sense.

Thanks for the help, I know I am a little slow let's say 😄

No problem.

One day I hope I can have this knowledge but I guess it's years of experience away perhaps

I was hoping I could find a clojure job in the future but this is like finding a unicorn perhaps haha

Not really. It depends on what you end up doing. Or on what you want to do. Knowing HTTP and all of the related stuff maybe useful for some, but it's not that helpful for someone that e.g. writes desktop software.

that's true

hmm, that's a good point

Even for web development, the vast majority of what there is to know can be more or less safely skipped simply because "it just works".

true

I guess my toy problem is actually a little advanced in the respect it doesn't just work haha

because the NBA API is little more less client friendly?

Probably. I have never had to deal with CORS at all - I have never needed my frontend to load someone else's resources that have been protected with CORS. Maybe someday I will, I don't know.

haha

okay so I got an API that provides a nice response ;D

question is, how do I begin deploying something like this to heroku?

By reading Heroku documentation. 😉 It's all there.

:thumbsup:

Will do