Fork me on GitHub
#fulcro
<
2019-11-19
>
cjmurphy19:11:42

Using js/setInterval I've setup a function that regularly reads from app state and also regularly does comp/transact! to change it. I'm always been under the impression this is quite a legitimate thing to do. And indeed there are no problems with Fulcro itself - the application under development keeps working. But after a while Fulcro Inspect just becomes an empty map. Is this something that could be expected to happen with Fulcro Inspect? I can raise an issue but just wanted to check here first.

tony.kay19:11:50

@cjmurphy So, inspect does a diff from state as an optimization, and it is known to have occasionally issues. There is an open issue. Basically we just need to fix it so that it sends over a complete db again when it detects an error.

cjmurphy19:11:02

I'll leave it then. Thanks. I was looking at the issue. Now I look at it more closely (and refresh my browser) I see you changed the title so it isn't specifically about tempids.

Thomas Moerman21:11:18

General Q: in Fulcro 2.8 I tend to have a distinction between "Render" components and "Fetch" components which are typically a bit shallower in the data they query, because some data might be loaded from another starting point in the graph. Is this approach idiomatic in your opinion? Are there any recommended common patterns?

cjmurphy21:11:55

You have to use the "Fetch" components if you don't want to re-read common slow changing data ('lookups') over and over. In a larger application I would think that loads would be done with "Fetch" components more than "Render" components.

Thomas Moerman21:11:26

Indeed, that's my current approach. In my current project, the data is quite "interlinked", making multiple entry points in data graph possible, but this also increases the risk of having too large fetch operations (walking unnecessary links) if you're not careful..

cjmurphy21:11:47

Using fetch components also helps when you get into the situation where your data will be deleted on the client because the client asked for it but it wasn't found on the server. Solution is for the client to ask for less, doesn't matter that not querying for the whole of the component - in fact its usually an advantage for 'payload' reasons. And trying to return less from the server was what brought up the 'data being deleted' issue in the first place. So it all works out 🙂