This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (2)
- # beginners (69)
- # boot (2)
- # calva (15)
- # cider (4)
- # cljs-dev (8)
- # cljsrn (1)
- # clojure (38)
- # clojure-spec (2)
- # clojure-uk (6)
- # clojurescript (6)
- # cursive (12)
- # data-science (1)
- # datomic (6)
- # emacs (10)
- # figwheel-main (12)
- # fulcro (41)
- # nrepl (1)
- # re-frame (16)
- # reitit (1)
- # shadow-cljs (6)
- # spacemacs (2)
- # speculative (1)
- # test-check (9)
so what is the current best practice for "expensive" computed properties? ie. something that should only be computed when actually queried but must be computed on the client
I am doing complete guess work here (I’ve no experience with what you are asking and just started using Fulcro) but would it be possible to compute these in a web worker and treat the web worker as a remote?
nah worker is overkill. it only takes around 100ms to compute and isn't computed often.
@U05224H0W I suggest you try the new
:pre-merge, so when the data is loaded you can at component level do any expensive caching, think of it as a more localized way to do post-mutations
I'm currently using it to write an index explorer for pathom, and in this thing, when I load the index I have to generate a bunch of extra local index to arrange the data in way that's faster for the client to read, you can find it here: https://github.com/wilkerlucio/pathom-viz/blob/index-explorer/src/core/com/wsscode/pathom/viz/index_explorer.cljs#L319
Is the use-case that you plan to vary the query, and only when it matches this “magic prop” do you compute it?
All read-local is going to do to you is make you figure out the caching mechanism in the context of a parser, and deal with recursive parsing for everything leading up to your prop…I really don’t think read-local should be used at all at this point.
I typically cache the result in app state under a :ui prop, and use whatever logic makes sense for cache invalidation…timestamp, flags, etc. So, the parent where the computation lives does it and does a
m/set-value!, and passes it as computed to the child.
thx for the pointers. I opted to do the write in the transaction that triggers the display of stuff. kinda don't like that the tx has to know what the UI is going to display but seems alright for now.
@ahmed1hsn A selection checkbox, the current scroll position, etc. Anything that is not persisted on the server. The prefix prevents the prop from being included in queries to server on loads.
@kwcharllie379 I am very much a beginner with Fulcro so don’t take my word as gospel, but I think the answer is almost definitively yes. Fulcro communicates with servers through remotes, which as far as I understand can be anything that has the ability to read and respond to Fulcro transactions. The Fulcro backend is one such possible remotes, but you could roll your own.
it’s recommended that you use pathom to builder your API wrapper, and pathom can run in the client or server (so you can wrap your backend API at whatever layer is appropriate for you)
@currentoor yep that’s an interesting approach as well; you could have pathom run on the client and run API calls
and we have pathom in the client to wrap this 3rd party REST API we use directly from the client
@currentoor interesting, can you tell me what drove the decision to make the 3rd part requests direct on the client instead of delegating to your server?
it’s OpenALPR and API that can take images of vehicle and returns license plate numbers and other details about the vehicle, like make and model
since it involves passing images around it was much faster to do from the client rather than through the server
through the server it could take several seconds, directly from the client it usually takes 1 second or less
nice, makes sense, in the future once pathom supports graph to graph requests, you could even have a single parser on the client that handles all the local resolvers in the browser and delegate the rest to the server (which will be known because of the downloaded index, a bit like what happens to graphql now, but better)
the cool part about a unified one is that you could move resolvers from client/server as you see fit, and the UI would never notice 🙂