Clojurians Log v2

happy to answer any questions here (which will also help us improve the qlkit FAQ https://github.com/forward-blockchain/qlkit/wiki/Qlkit-FAQ)

Hi @tacosundae great tl;dr in the reddit thread!

(unless that's a different "tacosundae")

In the FAQ you state that the queries are static and that the smarts should be in the parsers. What I seem to be missing is how to set the query parameters from a component. You give the example of [:persons/search {:name-prefix "smit"} [:person/name] [:person/age]]. How do I link that up in the component?

tyup that was me ^^

@tacosundae Let me rephrase to see if I understand your question: You're saying you have a component, let's say hypothetically a "search box" that has differing data needs over time, i.e. you want a parameter on the query to change when the search text changes. Is that what you're asking?

exactly

Is the data that satisfies the query coming from the client state or from the server? (my answers are different in each case)

I suppose that would make a difference. I can hazard a guess to the server case. chat about the client?

what*

Well, let me address the server case first, just to organize my own thoughts...

My experience with these query lange systems is that you end up in a world of pain if you have a parameterized query in the UI that gets sent to the client parsers, then later to the server parsers. A much better approach is to "lift" the search parameter into the global client state, making this a two-step process. So the steps are: 1. The component sends a transaction [:widget/search-param-set! search-string] 2. The remote parser builds the parameterized query

I believe I see where this is going. you then have the parser parameterize the query from the global state?

For the client case, your options are either to do the same thing as in the server case, or to simply grab ALL the data into the component (a browser client just has a small amount of data anyway) and then just filter it directly in the render routine of the component (or do some fancier optimizations that amount to the same thing)

@tacosundae yes, so you have a read parser for :myapp/widgets (or if you want to break out search as a separate concern, :widgets/by-search-term) and that parser just pulls the :widget/search-param out of the client state

@tacosundae or you just use the alternate "brute force" approach and just grab all the widget data with the query and just filter it in real time in the component.

Qlkit makes the assumption that "client side computing cycles are cheap"

This may not always be an accurate assumption- OmNext definitely trades off better performance for a more complex library and that may be a better choice in some cases

Thanks alot, that clears it up for me. Btw (assuming this is conrad) will we ever have a Country of Clojure?

It's been discussed, never happened though- Writing books is a lot of work 🙂

I bet!

FYI this info is going straight into the github faq