Fork me on GitHub

you have some code to look at? i'm not following


oh nvm - why wouldn't you add the join to the query?


The join is in the component query. But when I do a load it’s not in the load query (nor do I want it, since it’s an UI concern). The problem is then that the incoming data cannot be “enriched” with initial state of form, because it won’t get normalized, because the query coming into the pre-merge doesn’t have the form join.


I have query like this on component defsc

:query [::sepa/full-name ::sepa/address1 ::sepa/address2 ::sepa/iban fs/form-config-join]
The I issue a load
(df/load! app
          ident                 class
                 {:remote :storage
                  :post-mutation `dr/target-ready
:post-mutation-params {:target ident}})


Then I get this in my pre-merge as query:

[::sepa/full-name ::sepa/address1 ::sepa/address2 ::sepa/iban]
so if I add form stuff in pre-merge it doesn’t get normalized


Do you not use add-form-config in the initial state of the component?


doesn’t really solve much as I have to reset the whole thing, since the load brings in pristine data…


i'm sorry I'm no longer following what your issue is, without some component code I can't help any further


this makes me think of a similar approach to visualize the big picture of Fulcro, the most powerful full-stack web framework in Clojure ecosystem

👀 2

I'm playing with the Fulcro native template and I'm having trouble getting the electron inspector to connect. I'm on windows using the Android studio emulator. The app works fine but the inspector doesn't connect and every second the following is logged:

2020-05-18 09:33:58.210 6624-7512/? W/ReactNativeJS: WARN [taoensso.sente:1287] - Chsk is closed: will try reconnect attempt (117) in 1000 ms
Given that the app connects to the server I'm pretty certain I have the networking configured correctly. The correct connection info is logged on startup:
[app.inspect-native-preload:8] - Installing Fulcro 3.x Inspect over Websockets targeting port  8237  on
I'm a react native dev by trade just starting to learn CLJS so I hope I haven't done something obviously wrong here but the connection closed message doesn't give me much to go on. Any pointers on where to look? thanks!


@andrew513 I don’t remember what the android emu does for networking. I have not personally tried inspect with the android emu


examine all of the networking kinds of things…your machine’s IP on the LAN, etc.


@tony.kay Android emulator always puts the host machine at The example app connects to the server without problem at that address. It's only inspect that will not connect. For that reason it seems unlikely to me that it's an emulator networking issue. Unfortunately being so new to clj/cljs I'm not sure how to gather more information about the issue.


@andrew513 the port has to be right on both


you sure the inspect tool is set to the right port?


and it’s the other way around…you’re connecting from the app to inspect


so you need to know your machine’s IP, not the app’s


Yes, it's set to 8237 on both. I've also tried the direct IP of my machine and also using adb-reverse to allow localhost access on 8237... The behavior is always the same.


sorry, sleepy


I see you had it in the right direction 😜


haha no problem 😃


that’s really all there is to it: Inspect listens on a port, and the app connects to it. The only problem I can think of is that the traffic isn’t routing


what OS are you on?


oh, you said: windows


windows 10. It seems really odd to me that the app can connect to the server without problem but for some reason the inspector isn't working


I’m not sure anyone has tested Inspect on Windows


Electron runs the server-side on node, which in turn uses sente, which in turn uses…hm, don’t remember


the express adapter


so, I’d check to see if node express websockets has any known issues on windows


you could also try running inspect from sources: (the steps are from project root, not the electron dir, except where it tells you to cd)


sorry, that’s the readme


not sure what would be different, other than you could perhaps add more debug messages and see what’s going on…or debug windows nodejs deps


I've never used electron myself but I've used other react native devtools built on electron without connection issues to the emulator. It seems unlikely that it's an electron specific issue. I'll give it a shot running inspect from source to see if I can figure anything out. Seems like there are several open PRs about the same issue on the sente repo about react-native being broken.


Not sure if that's relevant or not though


Hm. That could be it. We do have a patched sente we are using on our mobile apps. It is on clojars at: org.clojars.currentoor/sente      {:mvn/version “1.14.1-SNAPSHOT”}


and you have to do exclusions in deps to make sure you don’t get both


i.e. com.fulcrologic/fulcro         {:mvn/version “3.2.6” :exclusions [com.taoensso/sente]}


sorry for the trouble…I’m using Fulcro native, but I don’t use windows nor the android emu…right now all targeted at iOS actually


so Android isn’t getting much attn


No problem at all, hopefully I can get this figured out so it works on windows for others and I'll learn something in the process since I'm a total clojure newbie. Fulcro looks amazing btw, I love the design decisions behind it and I'm excited to try it out while learning cljs.


Thanks for the tips I'll make sure to do that. I just loaded up the react native template on my macbook to double check and it connects to the electron inspect with no issues there so this is definitely a windows/android issue I'm facing.


that’s good to know


windows networking has always been….fun?


Sure if by "fun" you mean "rip your hair out frustration" haha. Working with react-native on Android can be that way too. Some of the quirks around android are "fun" in the same way.


@tony.kay Figured it out. It was that bug in sente. I overrode the dep by changing my deps.edn like so

org.clojars.currentoor/sente      {:mvn/version "1.14.1-SNAPSHOT"}
           com.fulcrologic/fulcro              {:mvn/version "3.1.8" :exclusions [com.taoensso/sente]}
Then I added the following to :closure-defines in shadow-cljs.edn
com.fulcrologic.fulcro.inspect.inspect_ws/SERVER_PORT 8237
com.fulcrologic.fulcro.inspect.inspect_ws/SERVER_HOST ""
and now it connects to electron inspect without issue. Can also do it without specifying host and port by using the following adb
adb reverse tcp:8237 tcp:8237
so the app can connect to the inspect instance as if it were on localhost

👍 1

Maybe send a PR to the Fulcro native template mentioning this to help future users?


I don’t want such a PR, thanks


this is a sente issue. I would accept a README note


Sorry, that's what I meant


@U0522TWDA I had already sent a readme note PR before I saw your message 😃


Awesome! Thank you!


I'm trying to trigger a remote load! when a component mounts and I want to pass a param that is read from the URL. I'm seeing the current-route call return [] in componentDidMount, but I can see the path-segment in the state db and the router state is routed, so I'm not sure what's wrong.

(defsc TodayView [this props]
  {:query         [[::sm/asm-id ::root/TopRouter]]
   :ident         (fn [] [:component/id :today])
   :route-segment (-> r/routes :today :segment)
   :initial-state (fn [_] {})
                  (fn [this]
                    (log/info "CURRENT ROUTE " (dr/current-route SPA this))
                    (log/info "CURRENT ROUTE2 " (dr/current-route SPA))
                    (let [props (comp/props this)
                          r     (get props [::sm/asm-id ::root/TopRouter])
                          path  (get-in r [::sm/local-storage :path-segment])]
                      (log/info "routing path: " path))
URL is: log output:
routing path: ["today" "2020-05-18"]
and during render the call to (dr/current-route this) returns correctly


@danvingo current-route analyzes the current dynamic query. Is this an initial overall application render?


I don’t generally recommend using react lifecycle for this kind of thing…esp if you’re using HTML5 history API etc. Too many timing things that can go wrong


but I cannot, off the top of my head, see why this should not work


well, given the code you’re showing


there’s obviousl a lot more going on in your app


you’re better off using something like transact! to put your desired action into the queue for processing…or :will-enter so you can use route params as they are specified


if they are on the URL, then you are obviously pulling them off in some other layer of code and calling change-route, and the proper place to put routing behavior is into the routing hooks, not React’s lifecycle


Thanks for the reply. yea this is on initial load of the app, i'm calling change-route on boot, which is correctly being called - everything else with routing is working, just not seeing the current-route come through. I'll try using will-enter and see if that works.


Things are working now, one thing I noticed is will-enter is being called 3 times, so I'll have to add a guard clause or a debounce I suppose


That’s what route-deferred is for


docs state that: must be side-effect free


i see it now, sorry I usually go through the docs first, a bit tired today


@roklenarcic try 3.2.7-SNAPSHOT and see if that fixes your merge issue


at first glance it works


I think that is actually the correct fix. The middleware should never rewrite an actual load, so that defensive bit of logic could break something if someone was rewriting loads at the middleware layer, but I have no idea why you would want to do that at that layer…it would just make the stack above it really confusing, so I’m ok not supporting it.


If someone really needs that, they can plug in a custom load mutation, which is totally supported.


this makes things so much easier for me


I can stick a generic pre-merge on all my form components


yeah, sorry that got messed up. The mark missing was broken, and I did a patch for that, but got over-zealous and changed which query was used for actual data merge


I use UISM to manage form lifecycle, not pre-merge, so it didn’t break anything for me.


I’m just looking for the easiest way to initialize forms, when changing route post-mutation is already taken by dr/target-ready , so I like pre-merge, not sure what to do with UISM here 🙂