duct

Danny Almeida 2020-02-10T00:00:14.017Z

sorry for being a noob, but how do i print the config ?

2020-02-10T00:01:27.017200Z

(prn config)

2020-02-10T00:01:48.017400Z

In your dev namespace, I should add.

Danny Almeida 2020-02-10T00:01:55.017600Z

thank you πŸ™‚

Danny Almeida 2020-02-10T00:02:01.017800Z

yes ..i am in dev namespace

Danny Almeida 2020-02-10T00:02:08.018Z

thank you again for being so prompt

2020-02-10T00:02:11.018200Z

I think there might be a pprint as well which formats it better.

Danny Almeida 2020-02-10T00:02:29.018400Z

yes.i have included clojure.pprint

Danny Almeida 2020-02-10T00:02:36.018600Z

for debugging purposes

2020-02-10T00:02:36.018800Z

You may need to (prep) the config first, or just run (go).

Danny Almeida 2020-02-10T00:02:54.019Z

thank you

2020-02-10T00:03:05.019200Z

The config var holds the configuration after all the modules have been applied, so you can see exactly how it’s configured.

Danny Almeida 2020-02-10T00:03:48.019400Z

that's great .. now i can see all config variables being pulled

Danny Almeida 2020-02-10T00:03:52.019600Z

didn't know that.

Danny Almeida 2020-02-10T00:05:48.019800Z

it's working now.. cheers πŸ‘:skin-tone-3:

2020-02-10T00:24:29.020Z

np

g7s 2020-02-10T09:41:10.021300Z

If anyone is using duct and develops ClojureScript using shadow-cljs I have put together a module for that https://github.com/g7s/module.shadow-cljs

πŸŽ‰ 2
teodorlu 2020-02-10T10:27:14.021600Z

I was looking for just this a few months ago. Thanks for releasing! Are you following the Duct reloading scheme, so that Duct controls when the CLJS source is reloaded?

g7s 2020-02-10T10:31:11.021800Z

The updates to the cljs source are done by shadow because AFAIK it doesn't provide an API so that we can do this programmatically. If you are willing to investigate further I will be glad to help in the process.

g7s 2020-02-10T11:02:36.022Z

Now that I think about it shadow has this kinda built in. You can pass to a build :devtools {:watch-options {:autobuild false}} and then from the repl call (shadow.cljs.devtools.api/watch-compile-all!) to trigger a compilation of all your builds. Is that something you would like to see done automatically by the duct module? say that if for a build :autobuild is false then (reset) will do the (shadow.cljs.devtools.api/watch-compile-all!) thing?

Chris C 2020-02-10T14:53:14.025500Z

Hi, perhaps a silly question. I've got a bit of middleware within the config that I want to have different behaviour in the tests than in prod. I was thinking to pass the implementation I want, depending on the environment, but not sure how to do this. Thanks for the help in advance

2020-02-10T14:55:15.025600Z

You can add a :duct.profile/test profile to your configuration with the overrides you need, and only activate that in tests.

teodorlu 2020-02-10T15:05:34.025800Z

No strong preference, but I'm curious about the question and any experience reports. I haven't used Duct and/or Clojurescript in a while, so I'm not certain what behavior would be best. I do remember recalling Luminus starting to become really heavy once auto-compiling CLJS was turned on, which slowed down my REPL reduced developer experience somewhat.

Chris C 2020-02-10T15:13:16.026Z

Sorry for the stupid question, but how do I do that? I'm rather new to Clojure. I've got a profile being used for tests, but not sure how to replace the implementation of the middleware and not the routes.

Chris C 2020-02-10T15:13:35.026200Z

I'm not sure if that is too specific to the implementation to be of help

g7s 2020-02-10T16:08:56.026400Z

I have no experience with Luminus but I know that shadow is pretty fast. I am working on a sizable project and the compile times are barely noticeable. I actually use the autobuild and I am pretty happy

πŸ‘ 1
kwrooijen 2020-02-10T16:13:47.026600Z

You can change the arguments passed into the implementation (init-key) of your middleware. :duct.profile/test can use other keys instead of your prod implementation. Then the middleware implementation can look at those keys and do whatever it needs to do based on that

2020-02-10T16:14:00.026800Z

When the test profile and base profiles are merged together, any configuration in the test profile overrides configuration in the base profile, similarly to how Leiningen profiles work.

kwrooijen 2020-02-10T16:19:34.027Z

Simple example (just pseudo code, not tested). Skip the auth middleware if test is running.

kwrooijen 2020-02-10T16:20:35.027500Z

Not sure if this is really good practice, since you're putting test related logic in the middleware

kwrooijen 2020-02-10T16:21:22.027700Z

However, if I'm not mistaken. This is how you could add arguments to keys in specific profiles