Fork me on GitHub

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:






can't do it in render since it takes too long


The standard best practice is to do it in a post-mutation if it is a load.


I mean, component-local state isn’t a bad option for caching


(you can see old/new props in componentDidUpdate)


new lifecycle getDerivedStateFromProps


depends on the source of the data I guess


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.

Ahmed Hassan13:01:56

In section 3.4.3 of Developers Guide: What is example of UI-only properties?


@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.

Karol Wójcik20:01:48

Is there a way to use fulcro as only client library?


@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.


@hmaurer is correct, backend can be even be a rest API


or graphql or whatever


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


or simply hit local storage / whatever


yes, in our project we have pathom on the server for our main API


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


as we need these license plates decoded in real time


and unnecessary overhead for our 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)


I guess you currently have multiple remotes on the client, right?


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 🙂


yeah that is pretty cool, though having separate removes is also not bad


@kwcharllie379 the point is, use pathom to fulfill fulcro’s query needs and you can essentially do whatever you need