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

:read-local?

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

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.

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?

correct

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