@levitanong just released inspect beta3, this will stop loading index at start (also make sure the extension is updated to 0.0.4)

It gives you this: https://github.com/wilkerlucio/oge inside of the devtools. So basically a remote query development tool

@wilkerlucio When do you load the indexes?

Ah I found the button

I like that solution also makes it easy to update them, or us the view without pathom

@levitanong the index provides auto-complete when doing queries, its a feature from pathom connect

@mitchelkuijpers glad to hear, that buttons always worked to refresh the index, I just removed the automatic trigger from start 🙂

@wilkerlucio cool! So you said it doesn’t load at start anymore. How does one start it?

@levitanong click on the grey circle on the query tab, tab will trigger an index load

and if you server can provide it, then its used for the auto-complete

@wilkerlucio hmmm. it causes the multimethod error again. non-breaking though. I’m curious, why does it try to hit all my remotes?

right it shouldn't, it should only refresh the index on the remote you clicked on the button

are you using pathom with connect? otherwise your parser will probably don't know how to provide the index

Hmmm… Looks like I’ll have to read up on pathom. I’m not using it in any capacity at the moment.

yeah, connect is a much higher level feature compared to the building blocks on pathom, I have to rewrite the docs to put it first

the current ones might get the wrong impression about how this should be used

but for now, I recommend checking the connect session in the docs: https://wilkerlucio.github.io/pathom/DevelopersGuide.html#_pathom_connect

and if you are not familiar with the concepts, I gave a talk where I explain most of the core ideas: https://www.youtube.com/watch?v=r3zywlNflJI

The biggest problem with graph APIs (fulcro or graphql) is lack of a good client caching story. For instance I have a list of documents. Document that have status Archived won't change any more. With REST I do one GET for list of document IDs, then a bunch of concurrent gets to load details. Archived documents are returned with a massive max-age header. They are now client cached and won't be requested anymore. With graph query you pull everything in one query so you get lower latency, but a single non-cacheable result ruins cacheability for all documents in the response.

It's easy to add client cache headers to REST controllers where possible, hard to do so for graph API.

@roklenarcic but you can be smarter about loads, when you are loading new data, you can strip the keys you already have, this is actually way more flexible then the rest model since you can pick and choose at any point which attributes you want to load from the server, might require some initial structuring but in the end I think you get the best out of graphs, if you need even more flexible cache, you can layer parser over parser and cache stuff directly on the client using local storage or even indexeddb

Of course, server caching can be better.

SPAs tend to have little client cacheable content anyway

and any BLOBs you can put behind a REST interface and write another fulcro remote

then slap a varnish in front of that REST

@jasonjckn sorry, no. I could turn the asserts into warnings for defui, and leave the harder-core checking on defsc perhaps…then again, not sure I’m willing to disable a sanity check for a legacy deprecated API that no one should use 😉

Yah, well not going to push very hard for this but that would definitely be helpful here, such a change would still be inline with your design goals since I believe the only reason for defui is backwards compatibility with untangled, and that extends to supporting the old v15 react api, which is still supported in v16.0 but deprecated, also this deprecation of react legacy API showed up in fulcro between 2.4.x and 2.5.x which is a bit arbitrary.

it’s clear we’ll have to migrate off this API one day or another, but as of now, just trying to take the shortest path to fulcro, and that’s a whole other undertaking.

Just release Fulcro Inspect extension 0.0.5 and jar version 2.2.0-beta4, I recommend everyone using to upgrade to it, the major change is that the encodings for transit are fast now, even when you have non-standard data in it, if you have a large app this will make a good performance difference. And a small extra: if you click on the button to reset the app state while the slider is the current state, you will trigger a simple force rerender on the app.

Inside a mutation I have the following code (prim/get-props (:component env)) and it’s returning nil props , and the component is non-nil there’s no way this could have nil props because (:ref env) is non-nil, so it clearly has identity which come from props

(defmethod fulcro.client.mutations/mutate :default [env k params]
  (js/console.log "mutate " k " => ENV: " env)
  (js/console.log "component c = " (:component env))
  (js/console.log "component props = " (prim/get-props (:component env)))
  (js/console.log "component ident = " (prim/ident (:component env) (prim/get-props (:component env))))

@tony.kay perhaps another bug ?

ah i switched to prim/props and that solved it, nvm

@tony.kay instead of eliding asserts, this worked

(alter-var-root #'fulcro.client.primitives/validate-sig (constantly identity))

@wilkerlucio trying fulcro-inspect for the first time, on your newest release, “Fulcro app not detected”

:cljsbuild
  {:builds {:dev {:source-paths ["dev/client" "src/client"]
                  :figwheel     {:on-jsload "cljs.user/figwheel-reload-hook"
                                 :websocket-host :js-client-host}
                  :compiler     {:main                 "cljs.user"
...........
                                 :recompile-dependents true
                                 :source-map-timestamp true
                                 :external-config      {:devtools/config {:features-to-install [:hints :formatters]}
                                                        :fulcro.inspect/config {:launch-keystroke "ctrl-f"}}
                                 :preloads             [devtools.preload
                                                        dirac.runtime.preload
                                                        fulcro.inspect.preload]
                                 :optimizations        :none}}

[fulcrologic/fulcro-inspect "2.2.0-beta4" :exclusions [fulcrologic/fulcro fulcrologic/fulcro-css]]

i’m using Chromium

Is there a way or future plan to support tolitius/mount, or any other component system, for that matter?

@jasonjckn I never tried on Chromium, did you get any errors? the extension icon "lights up" when you open the page?

@wilkerlucio it doesn’t light up no

@wilkerlucio when I click on the button I get the error “Fulcro app not detected”

what version of fulcro are you using?

what browser should I use? chrome canary ?

2.5.8-SNAPSHOT

no, regular chrome is fine, weird that isn't detecting, hadn't see that before, it should light up when the content script detects the fulcro inspect injection (it writes something on the DOM)

is this compatible with dirac?

I never tried with dirac

just use the simple devtools

but I don't see what would break there

you can try making a more clean slate to see what might be getting on the way

you see the log on console about Installing Fulcro Inspect?

no

ok, so the preload seems to not been loaded

is figwhell and preloads work fine on :optimizations :none?

yes

my dirac preloads work

that’s weird

@jasonjckn yeah, can you try bursting all caches and trying again?

anybody found a way to work around performance issues with semantic-ui-react ? my compile time is 11s 😞

i saw tony mentioned something months ago that it was on google

but couldn't find any more recent discussion

@chrisjswanson this has to do more with the compilation process, not with fulcro, you probably have better answers at #shadow-cljs if you are using it, or #figwheel

right on, thanks I give that a try

Just release Fulcro Inspect extension 0.0.6 and jar version 2.2.0-beta5, this fixes a case where the fulcro app is too fast to start and the content script wasn't ready to catch the messages, causing the inspector to not refresh on page updates

so it looks like i was wrong - this isn't a semantic-ui-react issue. i created a blank lein fulcro project and just ran cljsbuild auto - still seeing really long compile times ("src/main" in 38s). By comparison, the same exercise with lein luminus compiles in 1.5s

maybe not a strictly fulcro issue, but it does seem to have something to do with the way the template is configured by default