In ClojureScript, db-refresh is expected to be a map with :before and/or :after keys with function values. https://clojurescript.org/tools/testing#fixtures

I also burnt myself on this difference!

@UCW9TUDNK does :each run for every (is ...) or for every deftest?

Pretty sure it's every deftest, otherwise I would have loads of failing tests..

is there a strategy for resetting the db for every (is...)?

other than sandwiching a reset function throughout?

Not that I know of

I have the following:

(defn db-refresh []
  (dispatch [:initialize-db])
  (dispatch [:update-filter true "cat"])
  (dispatch [:update-filter true "cat1"])
  (dispatch [:show-products products])

  (prn "dispatched!!!!!!!!")
  )

(use-fixtures :each {:before db-refresh :after #()})

Could you try using dispatch-sync instead? If that doesn't help, it seems like there's something wrong with your deftests or test runner.

but calling (db-refresh) in the function explicitly works, so would dispatch-sync solve the problem?

I think it should work with a macro.

Could you provide an example? I'm not too familiar with writing macros.

I'm not that fluent myself. Here's a good tutorial: https://www.braveclojure.com/writing-macros/

Thanks. Looks like it was suprisingly easy!

user=> (def ops '("ONE" "TWO"))
#'user/ops
user=> (defmacro value-key [op]
`(case ~op
~ops :yay))
#'user/value-key
user=> (value-key "ONE")
:yay

(str host "/some-route") ?

(http/get (str (:base-url config) "/some-route")) and config map contains the whatever is the correct base-url

how to set up config?

How do I separate config based on whether I'm in production or development? My production environment is a docker container running on heroku

You could for example pass a configuration file name via command line arguments or environment variables docker run image-name java myfile.jar /path/to/config-prod.edn or docker run -e CONFIG=/path/to/config-prod.edn

or override specific environment specific bits in configuration: docker run -e SERVER_ENDPOINT= -e DATABASE_ENDPOINT= image-name

thats with plain docker, I am not familiar with heroku. It most likely has a way to set environment variables.

https://devcenter.heroku.com/articles/config-vars

Then you can construct the config map based on the environment. config is just a normal map. For example: (let [config {:server-endpoint (System/getEnv "SERVER_ENDPOINT")

I'd mainly like to do any npm script running necessary for a particular alias

Yeah, the auto-generated gunk from Rust. I’m happy to wrap it in something more palatable for shadow-cljs manually if that’s what it takes, I’m just not sure how.

shadow-cljs has no support for wasm yet so you kinda can only load the JS like they intended which sort of means webpack

Oh no, not webpack. Does shadow play well with webpack?

I'd just produce a separate .js file that exposes some global variable and load it separately from the CLJS output

you can combine them but don't really gain anything

I haven't looked at the code rust generates in a while

it used to change like every few days

dunno if its more stable now

It hasn’t changed for the month and a half I’ve been using it at least. But I guess WASM itself is evolving rapidly as well.

yeah the wasm import spec is still not finalized I think

“WebAssembly CG members representing four browsers, Chrome, Edge, Firefox, and WebKit, have reached consensus that the design of the initial WebAssembly API and binary format is complete… This consensus includes a JavaScript API and binary format accompanied by a reference interpreter.” Maybe we’ll see fewer changes now.

Btw, it occurs to me that a good reason to combine them would be in order to produce a redistributable CLJS lib

I meant this https://github.com/WebAssembly/esm-integration/tree/master/proposals/esm-integration which is still stage 2 and not implemented in any browser

and that will also be rather complicated to support in CLJS

so we'll see where all this goes I guess

Yeah, bit of a PITA to have to load the file manually rather than via a script tag, but not a dealbreaker I would think.

the question really is what the generated rust code does

the last time I checked it was using some webpack specific features that shadow-cljs doesn't have

using wasm from CLJS is easy .. the required JS glue-code is the issue

So the problem is in consuming the exported functions from the glue code?

My understanding is that WASM only supports sending (vectors of) ints and floats across the JS <-> WASM border. Therefore, it makes a bunch of helper functions that converts strings to vectors of ints (and vice versa on the WASM side), then creates an export function for every endpoint exposed by WASM, using the string conversion functions inside those where necessary.

For data structures, I’m basically serializing, converting to string, reading the string, and deserializing into Rust. It’s like you’re talking to a server over a network (for goodness sake).

yes, wasm is basically all byte arrays. so to support calling functions with string arguments and so on you need some JS gluecode that does the conversions back and forth

thats all going to get better with WASI but thats still in development