Clojurians Log v2

Dunno if this would come in useful, but I just spent a bit of time to get a rough translator going from fulcro rad attributes => malli-schema format. It will also figure out what entities you have (based of of ao/identities ) and generate the joins required. It has lots of rough edges, but it's good enough for my use-case of dogfooding some random initial state when I need something. I didn't use spec because it's nearly impossible to generate spec1 at runtime. A better solution might be to override defattr to create a spec definition at compiletime, but I only thought of that after I wrote this 🙂. https://gist.github.com/JJ-Atkinson/796d8e124edf684def2283dd9759515d

Trying to get the https://github.com/fulcrologic/fulcro-rad-demo to add an Account in SQL configuration. Everything works fine till I try to add an account, then I get the error

originalMessage: "Data conversion error converting \"OTHER to ENUM\""

@tony.kay What is this line in fulcro.components for?

#?(:clj
   (defn -legal-keys
     "PRIVATE. Find the legal keys in a query. NOTE: This is at compile time, so the get-query calls are still embedded (thus cannot
     use the AST)"
     [query]
     (letfn [(keeper [ele]
               (cond
                 (list? ele) (recur (first ele))      <- THIS ONE ================================================================================
                 (keyword? ele) ele
                 (is-link? ele) (first ele)
                 (and (map? ele) (keyword? (ffirst ele))) (ffirst ele)
                 (and (map? ele) (is-link? (ffirst ele))) (first (ffirst ele))
                 :else nil))]
       (set (keep keeper query)))))

The SQL plugin is very alpha. Enumerations, in particular, are known not to work well. I’m actively interested in finding a maintainer, and currently don’t have time to work on it.

It’s used to generate compile-time errors around defsc to prevent common errors. Parameters don’t make sense in static component queries, and the generalized load support allows you to add them when you need them. This makes the use of dynamic queries that add them also largely irrelevant. Fulcro could support that, but I have no intention of doing so at the moment. The earlier versions technically did support this, but no one seemed to use it, including me (and not a single complaint from removal).

It was a source of complexity that I chose not to move forward with, given the amount of complexity it added to everything. I judged it “incidental”. I’m not dead-set on that judgement “forever”, but until I see really compelling use-cases that cannot be solved (reasonably well) with the existing APIs I have no interest in making things more complex based on the occasional “preference” to embed them that way.

My recommendation is to use namespaced keys in the params argument of load, move those into your server parsing env (so they propagate to children). The namespacing allows for a form of “targeting” of the query params. Granted that solution is not perfect, but in the real world with the real features of load, it has solved every case I’ve needed very easily.

Sorry, you asked about the specific line. Yes, that line is there to deal with the fact that one could technically embed parameters in queries.

and the error checking doesn’t care about them

When I talk about the query parameter stuff above, I mean that you used to be able to do this: [(:prop {:start ?start})] and then later call set-query to bind ?start to something. That’s the parameter support I dropped.

you can still call set-query and put parameters in the query of a component. It could technically have some bugs (I do not imagine it does), because no one uses it to my knowledge, but try it if you wish.

I am trying to. When writing (:comment/body {:truncated? true}), like above, I just get an Invalid expression error from cljs. When I quote the expression, I get was destructured in props, but does not appear in the :query I am trying to figure out how to fix this for me.

It doesn’t matter so much whether it works or not. It’s not really worth my time right now, but curiosity grabbed me.

I saw the specific line and though: “Great, I am not the first one to try this” 🙂

@tony.kay While I am already at it: Here are two questions that I thought about and would love your opinion whether these things make sense or not. I am aware that these things are just “sugar” and not a necessity. 1. How would I write a function for something like an … “anonymous component” for query purposes? I often have to write components just for the query:

(defsc Child [_ _] 
 {:query [:id]
  :ident :id})

(defsc Something [_ {:keys [children]}]
 {:query [{:children (comp/get-query Child)}]}
 (str "I have " (count children) " children!")
)

; to

(defsc Something [_ {:keys [children]}]
 {:query [{:children (comp/sc [:id] {:ident :id})]}     ; <- something like this   ; or (comp/sc {:query [:id] :ident :id})
 (str "I have " (count children) " children!")
)

(defsc NavDrawer [_ _]
 {:query [:open?]
  :ident (fn [] [:component :nav-drawer])

(defsc Root [_ _]
 {:query [{:nav-drawer (comp/get-query NavDrawer)}]}) 

; The db:
{:nav-drawer [:component :nav-drawer]   ; This seems redundant for singletons
 :component {:nav-drawer {:open? false}}

;;; instead NavDrawer with a single item ident
(defsc NavDrawer [_ _]
 {:query [:open?]
  :ident (fn [] [:nav-drawer]))

; would lead to this db:
{:nav-drawer {:open? false}}

1. Technically you just need to add the metadata that get-query adds, and have the :component in that have a component options ident (which in cljs is just an js object with some special fields). The only thing special about it is the component used for normalization; however, I do not see why you’d want that, because you should be doing the rendering in the child, and therefore should be writing a child anyway. Writing a separate component just for a query is a very rare thing indeed (your example is a contrived use-case). 2. you can certainly write a macro that transforms that, but I don’t want to add yet another syntax sugar onto a macro that already has so many little things like that. On the one hand it’s “par for the course”, but on the other what “table name” am I to auto-select for you? Also, since keywords without a vector mean :x => [:x (:x props)] having another special variant [:x] => [:component/id :x] along with [:x :y] => [:x (:y props)] or (fn [] literal-ident) is adding to a thing that is already a bit excessive, and doesn’t even follow the “sugar pattern” of pulling something from props to generate the ident.

A more solid use-case for (1) is (df/load! :kw (sc ident query)) where you want normalization of some data into the client that doesn’t have UI of that shpe

See configure-component! for ideas on making the query thing, but be careful: the component registry is normally part of the story, and your use-case probably doesn’t want to register, so you don’t really want all the mess that configure component does.

To 2.: Is it really another case? For singletons a table-name doesn’t make sense. I thought not about a keyword without a vector, but a vector with a single entry as a literal-ident (fn [] [:x]) Like you could for a normal map in clojure: (get-in state [:nav-drawer]) and (assoc-in state [:nav-drawer])

To test if your thing works, just make sure get-query and get-ident (both arities) work on it.

I see what you’re getting at. I definitely do not want to introduce that complication. It would affect a lot of things for no tangible benefit.

(state would then have to be able to contain card 1 vectors as idents, which would confuse all manner of things)

right, I don’t have tests covering the case for query params in component static queries but there is some legacy bit here and there that made it through the removal. Given the bug, then only way to do it right now is via set-query!

which you actually need to use anyway, since parameters (by their nature) vary

My general reasoning was: You need to pre-set bindings and parameters before they make sense, so why not just use set-query?

but because all that introduces the need for logic in the same code points as load, why not just use load params?

The answer, of course, being you want the params in a particular spot. My workaround mentioned before works quite well for me, but you still have set-query! if you really really need it.

Is it possible to watch changes in props of a child component? I want a parent component to be able to see if a child (form) component is valid (I’m using the non-spec validators)

Oops didn’t mean to pin that 😄

the props of the child flow through the parent

yeah, I figured 🙂

The trick is that if you use an optimized call the re-renders just the child, then you need to make sure the parent is refreshed (usually by using something like :only-refresh. Depends on renderer. Oh, in F2, which I think you’re using, you’d include a parent prop in the follow-on read

ah I see.. so on any updates to the child just make sure those transactions are also updating the parent ident

(transact! this [(update-field …) :parent-prop])

yep

got it, thanks

in F3 I figured out that the targeted refresh is usally not needed for performance (if you do other things right), so default is to render from root, which in turn makes doing that a non-issue…you don’t even have to think about it. It pushes the potential complexity off to an optimization step instead of troubling you with it from the outset as a pre-optimization

Speaking of validation, on initial load my fields are “unchecked” but once I edit one of them, the rest of them turn invalid. Is there a way around this? I’d rather not show validation messages until the user has tried to modify that field

I guess I just don’t see why editing one field would make the rest invalid

“edit one of them” is never and has never been the trigger

mark-complete is what changes that

and it can be called for a field or the whole form, but it is in your control

I see.. so what is the recommendation in this scenario? The onChange is causing the whole form to be invalid at this point

https://book.fulcrologic.com/fulcro2/#_completing_fields

add the field argument to mark complete

Hm. I thought that could be as simple as remove any checks if an ident is exactly card. 2. Ok. Thanks for your reply.

Does anyone has an example with two nested dynamic-routers, where both routers have a parameter in their route-segment? I am stuck with initializing the state correctly.

what are your route segments?

[„decision“ :process/slug] And [„proposal“ :proposal/id] or even [„proposals“] Thinking about it. I have problem placing another dynamic router in a target with a parameter. The second parameter isn‘t even needed.

should nest fine, but you need to make sure you pass a complete route to it…i.e. the vector of a route MUST have 4 elements in order to match

if you fail to specify a bit of the segment the routing will stop at that point and assume the sub-routes are “right” already

But how do I initialise the inner router?

It can‘t be initialised on app startup because of the parameter.

sure it can, you can initialize state and set root with set-root!, then use dr/route-to!

then mount w/o initialize

I use a “ready” flag on the root node to prevent rendering until things have settled (i.e. a ok-result handler on loading app config or something)