setting a the report/column-EQL field on the attribute to a bogus key seems to allow for those keys to not conflict, but that's obviously not the right solution.

I think what I really want here is a map from qualified keys to functions in the report options that will take the matched column attribute and return a query to be used in place of the qualified key... or an explanation of why I'm on the wrong track.

I don't fully get what you are after but would some of https://gist.github.com/holyjak/207ed33c9ee7e003b9a779fa47c32d91#reports help?

So, when you list columns in a report, that is what is used to generate the query...it's just a macro. The column-EQL on an attribute is typically what you want, and in that case you don't want row-query-inclusion, since those are added AFTER the columns are added, so you'll have dupes.

Make SURE your column-EQL is a map, since it is a single element of EQL. The only two values that make sense are a single keyword (the default) or a join (which is a map joning on the keyword of the attribute).

then you'll need a column formatter, since nothing will know how to render that column. Using a custom BodyItem (in which you hand-write the query and rendering of the row) is the completely general case, and ignores column-EQL and row-query-inclusion...those latter two options let the macro generate a row component for you, but if you specify one, then there is nothing to generate.

is it normal then to have attributes used just for ui then. Because I don't think I would want to override my attribute to have the same query as is needed by a ui component. Also, I can't seem to get the joining to work like described in that link, If I add my currency name attribute to my account report, it's not following it through the account/currency ref, so I think I'm misunderstanding that (I assumed that didn't work)

So I had a custom formatter, but I was trying to get the name pulled in, but if I specified the currency ref attribute, then I couldn't include that query (the name wasn't getting merged in)

so if I had an attribute to hold that query, pathom wouldn't really need it for anything because that job is being served by the currency ref

column-EQL is just used by reports. You are, of course, allowed to create attributes that are not tied to db schema, make resolvers for them, and use them in reports.

ok, I think what I need to do is becoming clearer

you're talking in "local code-speak" and have not shown me any code...so "currency ref" is gibberish

So, I usually do the following: 1. Implement the resolvers 2. Use Inspect EQL tab to make sure I can get the data I expect from the back-end 3. Add things to a report Sometimes I do 1/3, then if it doesn't look right double-check 2. There's really not much to it...it's just making a standard defsc for you with a generated row component.

That works out nicely. Thanks

That should work, assuming your value of initial state matches the real shape of BankAccountForm....NOTE: initial state for RAD forms is about FORM state, not COMPONENT state. You cannot initialize non-form data via that mechanism.

:ui/context, I imagine is NOT declared as a form.

If you want to hack in that kind of think you're going to have to work on a deeper level: E.g. customize the UISM fo/machine option, or try pre-merge (don't know if that will work in this case).

The cleanest approach is to extend the form machine with your own customizations..it's pretty simple to do since UISM machines are just maps...just assoc-in new events and such.

Yes I was wanting :ui/context to be in COMPONENT state. In this case it is annoying that FORM state and COMPONENT state are separate. There's just one locally created bank account.

It is in fo/field-visible? of a ::bank-account attribute that I'm needing the context, so perhaps from this I can get to FORM state, where I'll find :ui/context has been put. I looked in DB Explorer and couldn't find :ui/context. And anyway all I have to look into from this is props, so that's not really a go-er.

A locally created bank account needs to know the country of the user. Without RAD it would just be a local mutation to create the bank-account, so I'd easily be able to see context (that has country). With RAD things get trickier. Maybe there's a mutation hook...

you can add a link query to the query inclusion and get smething like user details from root level

That did the trick. Thanks 🙂

Given that componentWillReceiveProps is deprecated, I say the docs just weren't updated. You should use shouldComponentUpdate in this case, since it is called every time the props change.

Thanks for the clarification.

some tips here https://gist.github.com/holyjak/6ead10c0b447e098026f3e24e4f1e519#gistcomment-3825187

Thanks for the link, but I think that's a bit over my head at this level. I'm not clear how this text maps back to my question. Maybe this is a good sign I should take a break from trying to make things and go do the Advanced Minimalist Tutorial.

The idea is that for Clj write something that approximates the cljs thing. In the case of d3 - return empty svg / canvas?

BTW the UI does not need to be in Clj. If you don't plan to set up server side rendering then it's perfectly OK to rename the files to cljs. Don't make your life more difficult than it needs to be

Right, use cljc if you need server side rendering and return a dummy element if you don't mind the pre-data-hydration looking off, else just use cljs. wrt using d3, you can call everything from cljs, just need to get used to the slight syntax differences in examples, I find that the d3 works quite well with cljs and react. Use react refs to pass to d3 where dom elements are required. In general useful functions to know about when interop with js libraries is to-array on your data if the library has trouble iterating cljs datastructures, and sometimes return types of accessor functions are expected to be JS objects (but usually they are primitives in the end, so you can actually use cljs in the accessors)

Thanks guys.