Fork me on GitHub
#reitit
<
2018-11-06
>
ikitommi06:11:03

@shaun-mahood cool. for frontend, backend or both? router/mw/interceptor debugger planned, first step just logging the context & diff between steps. next step is a web-socket backed web-viewer/debugger, bit like 10x.

shaun-mahood15:11:56

The things I've used are all front-end only, but I've always struggled to understand what ring middleware is doing and loved using the re-frame interceptors for that. Excited for what you come up with! One of the most useful thing was being able to investigate the stack and queue and see the diffs in there - if I get a chance I'm going to try experimenting a bit with https://github.com/lambdaisland/deep-diff and see how well it works.

ikitommi15:11:42

The mw-screenshot diffing is from deep-diff ;)

shaun-mahood16:11:13

Do you think it would be reasonable to add something like a sieppari/debug-executor for development use that printed out the diffs (or a more targeted diff with only the changed data)? Not sure if it would require any changes to the interceptors at all, but from adding it directly into one interceptor as a test it seem like it could help a lot for development.

ikitommi16:11:06

In reitit, Implemented that with the :reitit.interceptor/transform option, interleaving the debug-interceptor between all others (at router creation time, per each route). One extra key to router config. I think same interleaving would work with sieppari

shaun-mahood16:11:56

Oh cool, I'll take a look and see how that works - thanks!

ikitommi06:11:08

Sieppari is being ported into cljs, which enables e2e-reitit/interceptor apps.

Hannu Hartikainen08:11:41

@ikitommi here’s my quick repro. https://github.com/dancek/reitit-frontend-spec-coercion-repro For some reason that fails both with the development and production build. Ie. I have no idea how it worked in my project in development…

Hannu Hartikainen08:11:10

Note that the code only logs to console. I didn’t want a reagent dependency.

ikitommi12:11:17

@hannu.hartikainen for some reason, the backtick in that setup resolved to current ns. should look up from clojurescript core by default.

ikitommi12:11:40

… int? gets resolve into spec-tools.form/int?

ikitommi12:11:26

cljs.user=> `int?
cljs.user/int?

ikitommi12:11:45

crap. need to fully qualify all of those to clojure.core.* for example.

ikitommi12:11:51

@hannu.hartikainen shadow-cljs is breaking things? with it:

(js/console.log `integer?)
; starter.browser/integer?
with lein + figwheel:
(js/console.log `integer?)
; cljs.core/integer?

ikitommi12:11:17

and because of that, the spec-tools form inferrer fails to resolve the type for the predicate. I guess #shadow-cljs would be a right place to ask about this.

Hannu Hartikainen12:11:05

i’ll try another repro of my actual issue later

Hannu Hartikainen15:11:00

i didn’t have time to try with my actual project but from the repro it looks like the issue is gone now that shadow-cljs was fixed

Hannu Hartikainen15:11:06

thanks for the help!

👍 4