This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-05-18
Channels
- # announcements (9)
- # atom-editor (29)
- # aws (17)
- # babashka (72)
- # beginners (83)
- # braveandtrue (3)
- # calva (7)
- # cider (16)
- # clj-kondo (15)
- # cljs-dev (146)
- # cljsjs (1)
- # cljsrn (8)
- # clojars (1)
- # clojure (96)
- # clojure-dev (19)
- # clojure-europe (53)
- # clojure-losangeles (1)
- # clojure-nl (3)
- # clojure-spec (7)
- # clojure-uk (235)
- # clojuredesign-podcast (5)
- # clojurescript (81)
- # conjure (73)
- # cursive (7)
- # data-science (1)
- # datomic (5)
- # defnpodcast (8)
- # emacs (3)
- # figwheel-main (34)
- # fulcro (83)
- # graalvm (10)
- # graphql (6)
- # helix (49)
- # jackdaw (3)
- # jobs (1)
- # joker (1)
- # kaocha (1)
- # mid-cities-meetup (10)
- # off-topic (17)
- # pathom (16)
- # re-frame (11)
- # reagent (18)
- # reitit (18)
- # remote-jobs (4)
- # shadow-cljs (63)
- # spacemacs (18)
- # specter (20)
- # sql (17)
- # uncomplicate (1)
- # vim (28)
- # xtdb (32)
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 normalizeddoesn’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
just seen this on reddit today https://orgpad.com/o/b1d2da1a-01b9-4aa4-a512-65ab03c6cc4a
This reminds me of https://roamresearch.com. See also https://github.com/athensresearch/athens, https://github.com/athensresearch/athens/issues/22
https://clojurians.slack.com/archives/C68M60S4F/p1590346044047600, https://roamresearch.com/#/app/careplanner/page/_DHXtNGVq
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
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 10.0.2.2
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
@tony.kay Android emulator always puts the host machine at 10.0.2.2. 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
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.
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
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
Electron runs the server-side on node, which in turn uses sente, which in turn uses…hm, don’t remember
you could also try running inspect from sources: https://github.com/fulcrologic/fulcro-inspect/tree/master/src/electron (the steps are from project root, not the electron dir, except where it tells you to cd)
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. https://github.com/ptaoussanis/sente/pull/357 https://github.com/ptaoussanis/sente/pull/353 https://github.com/ptaoussanis/sente/pull/366
this one looks the same as well https://github.com/ptaoussanis/sente/pull/370
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”}
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
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.
Great, good luck 🙂 The biggest beginner mistake is not taking the time to do something really small and make sure you understand :query
, :ident
, and :initial-state
. I highly recommend watching the YouTube videos on that, and playing with those concepts in the small before trying to build bigger things. It’ll save you a lot of frustration
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.
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 "10.0.2.2"
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 localhostMaybe send a PR to the Fulcro native template mentioning this to help future users?
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 [_] {})
:componentDidMount
(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:
http://127.0.0.1:8085/today/2020-05-18
log output:
CURRENT ROUTE []
CURRENT ROUTE2 []
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
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
@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 🙂