Fork me on GitHub
#fulcro
<
2019-01-27
>
thheller13:01:20

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

hmaurer14:01:05

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?

thheller14:01:09

nah worker is overkill. it only takes around 100ms to compute and isn't computed often.

wilkerlucio21:01:47

@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

wilkerlucio21:01:18

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

thheller21:01:46

interesting

thheller13:01:25

:read-local?

thheller13:01:46

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

tony.kay18:01:47

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

tony.kay18:01:06

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

tony.kay18:01:18

(you can see old/new props in componentDidUpdate)

tony.kay18:01:35

new lifecycle getDerivedStateFromProps

tony.kay18:01:41

depends on the source of the data I guess

tony.kay18:01:08

Is the use-case that you plan to vary the query, and only when it matches this “magic prop” do you compute it?

tony.kay18:01:23

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.

tony.kay18:01:27

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.

thheller19:01:01

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?

tony.kay18:01:06

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

hmaurer21:01:31

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

currentoor23:01:46

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

currentoor23:01:54

or graphql or whatever

currentoor23:01:53

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)

hmaurer23:01:35

@currentoor yep that’s an interesting approach as well; you could have pathom run on the client and run API calls

hmaurer23:01:51

or simply hit local storage / whatever

currentoor23:01:23

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

currentoor23:01:44

and we have pathom in the client to wrap this 3rd party REST API we use directly from the client

wilkerlucio23:01:56

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

currentoor23:01:15

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

currentoor23:01:41

since it involves passing images around it was much faster to do from the client rather than through the server

currentoor23:01:55

as we need these license plates decoded in real time

currentoor23:01:16

and unnecessary overhead for our server

currentoor23:01:12

through the server it could take several seconds, directly from the client it usually takes 1 second or less

wilkerlucio23:01:22

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)

wilkerlucio23:01:42

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

wilkerlucio23:01:29

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 🙂

currentoor23:01:32

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

currentoor23:01:27

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