Fork me on GitHub
#fulcro
<
2018-12-05
>
Andreas Liljeqvist13:12:46

in defmutation remote on client, is it possible to cleanup the datastructure before sending it? There are some computed attributes that can't be serialised, but are needed in the client

Andreas Liljeqvist13:12:58

Hmm... So I might be able to mutate the ast and pass it as argument to :remote instead of true.

tony.kay13:12:11

@andreas862 exactly

Björn Ebbinghaus14:12:01

Hey, I just created a new fulcro app from the lein template. I installed the fulcro inspect for chrome. The extension says: "Fulcro app detected!" And there is a console print: "Installing Fulcro Inspect {}" But the tab in the chrome devtools is empty and clicking on "Inspector" on one of the workspaces cards does nothing. Any idea what is going wrong?

souenzzo14:12:17

@mroerni reinstall the extension and do a "clean" build rm -rf out/ target/ ...

Björn Ebbinghaus14:12:01

Done. Nothing. 😞

Alex H18:12:54

a bit of a vague question, but does anyone have a performance comparison of fulcro vs reagent+re-frame - ignoring data fetching, just the mutation/event dispatch + query/subscription + rerender?

Alex H18:12:53

or maybe more specifically, does anyone know how subscriptions compare to the query-based approach when it comes to rerender, assuming both pull out of their respective "app-db" and nothing fancy?

wilkerlucio18:12:08

AFAIK nobody ran some benchmarks, from the a higher level I guess re-frame would be faster to update leaves, because it does local state updates, while fulcro always renders from the root and relies on immutable data structures fast check on componentShouldUpdate to get fast, so fulcro can be faster when many things change at once, but I'm just guessing, someone need to run real benchmarks in small and large settings to have some proper numbers

tony.kay19:12:36

@alex340 The current rendering algorithm in Fulcro is currently less fast than it could be, but I have not seen real performance issues “in the wild”. I removed some optimizations at React 16 because of changes to how React works in that version. I have ideas for adding optimizations back in, but am waiting for React 17 before doing that, since they are likely to change in a significant way then due to async stuff.

tony.kay19:12:46

You can still use react component local state for things that need to be super-fast (e.g. animations), but the normal overhead in query is usually so much higher than actual react rendering that for most intents and purposes the optimizations I have around queries are enough.

tony.kay19:12:04

(and the fact that everything is a pure react component that short-circuits unless props change)

Alex H19:12:03

yea, local state is always an option, but was wondering how it compares against re-frame subscriptions. Sounds like re-frame subscriptions, from a pure "FPS" point of view, might have an advantage as they don't necessarily cause root rerenders

Alex H19:12:34

but it's fair to say that there's like other bottlenecks in the system than a root rerender

Alex H19:12:51

unrelated - with re-frame, I've effectively built something around pathom where, if a subscription to a given EQL query misses in re-frame's app-db, it automatically sends it to the server, and then on the trip back normalizes results in the app-db, triggering the subscription again, this time hitting.

shaun-mahood19:12:49

Is this open source? There are at least a few people interested in something similar (including me)

1
Alex H19:12:14

no (t yet) - at the moment it's still a prototype. fully functional, but not terribly clean/elegant.

Alex H19:12:00

there's still too much repetition for my liking, in how the client-side pathom-connect resolvers are defined, and how the normalization parameters are specified.

shaun-mahood19:12:29

It seems like it would be tricky - glad you're working on it so I don't have to 🙂

Alex H19:12:26

With fulcro, it seems to me that there's no automatic triggering of a server-side query when a query misses in the client-side database, and instead one is expected to sprinkle loads over the place

Alex H19:12:36

Am I missing something with how that works?

wilkerlucio19:12:06

@alex340 yes, you are supposed to do that, Om.next tried to be automatic, but in real things that was really complicated to deal with, and you lose a lot of control, when you app grows you will tend to start be more selective about what to load when, explicit loads give you more flexibility on this sense

Alex H20:12:29

so you put your loads in e.g. your router transitions or similar?

wilkerlucio20:12:54

yes, I honestly have deal very little with routers, my apps are usually more app-like than side-like, so the flux is a bit different, but for sites that would be the case

Alex H20:12:27

one more question; if I have a list of, say, movies normalized into the client-side DB, is there some way of not having separate indexes for finding movies by name vs by ID?

Alex H20:12:57

with separate indexes, all indexes will need updating when a movie is added/removed. if there only was a single entity database from which indexes can be generated on the fly, that'd be a lot easier

Alex H20:12:38

or, possibly a better example - think some sort of stock management system, where each product can be in one or more shelves, and each shelf can contain one or more products. Each "stock" entry also has some properties of its own, such as how many of the product are on that shelf. I'd see the stock has its own entity normalized into the app-db with a :stock/id based index. But I'd also want to be able to query all stock entries with a given :product/id, or all stock entries with a given :shelf/id, without having effectively 3 indexes, having to maintain all 3 of them as products get added/removed.

currentoor23:12:33

@alex340 is this a very frontend heavy app?

currentoor23:12:25

because this sounds like something you need a database for, fulcro’s app state is a denormalized client app-state but it’s definitely not meant for arbitrary query capabilities like the ones your mentioning, it stores the state of your app (which screen to show, and other temporary UI state) and query results that have come back from the server

currentoor23:12:15

normally I’d let my serverside database handle indexes and run complicated queries from there, that does introduce latency though, but most of the time a little latency doesn’t hurt anyone

currentoor23:12:59

but if you really need 0 latency and want the DB on the client i’d suggest you use something like datascript as your database on the client https://github.com/tonsky/datascript

currentoor23:12:35

it supports arbitrary querying like what your talking about

currentoor23:12:22

then you could connect fulcro (or any other frontend framework) to it all in the client

currentoor23:12:24

does that make sense?