Fork me on GitHub

@claudiu Yep! That was it. Thanks. I am still at a point where I struggle to debug when things aren’t quite wired up correctly.


you're welcome, glad to help 🙂


I’ve been able to replicate this dx-react-grid code ( and trying to extend to track row selection with <Table rowComponent={TableRow}/> from the example at the bottom here: Still ramping up on React.js and not sure how to translate this code

const TableRow = ({ row, ...restProps }) => (
// eslint-disable-next-line no-alert
onClick={() => alert(JSON.stringify(row))}
cursor: 'pointer',
to fulcro. Thoughts?


I gave you some thoughts in #reagent


@donmullen The developer’s guide talks about dealing with factories…and so I would use the factory-apply thing to make something that can render Table.Row with regular props. Then I’d create a function that takes your desired argument list and put it together. See The only tough part for that example is the ... notation, since that is basically merging existing props into a list. If you write a cljs function that takes regular cljs data, then you can use merge, and then clj->js to send the final things.


If you’re wanting a vanilla js react component to consume that function, then you’ll have to accept js object at params instead (as is the case here). So, just use something like goog.object’s set to take what you’re passed, add things to it, then use that as your props.


Thanks @tony.kay - I’m a bit in over my head - but may be able to figure things out based on what you have said above. And thanks @lee.justin.m - got me one step further!


is fulcro reagent based? i gave some advice in #reagent because i thought don was using reagent but now i’m wondering if that advice won’t make sense


no, it is not


it’s an evolution of Om Next


well i never understand how the component-level binding works there either 🙂


All sablano is doing is a call to js React factory stuff with the class. That’s all the wrapper in the book does…it just gives you a function to call instead of some special data structure notation.


It looks like, from your example, that the react component is sending you an array of args…like it is varargs. That is (defn f [row & restProps] ...)


i think gen-table-row will receive a JS map, not a CLJS map. i think you need to convert to CLJS before trying to destructure


but then restProps in cljs will be a cljs vector, not a js array


and that is true, too. Destructuring isn’t going to work


Oh, I see…I misread the js example…I missed that it was destructuring


I don’t write any js these days, so I don’t read it well 😜


you have to manually destructure that with gobj/get or convert it to cljs first. I would do the former, because you’re just going to need the latter


so, pretend like “spread” syntax in js doesn’t exist…you have to write it like that


you can use into-array to convert a cljs list into a JS array


if you need to spread, use .apply


the incoming thing is a map with “rest” notation


first thing he has to do is get the correct stuff out


destructuring won’t work because it is a js map. Could use js->clj The main thing to realize is that all destructuring notations for cljs won’t work on raw js objects…that’s the main problem


(by the way, when I have cljs code that is marooned in a javascript callback (like gen-table-row), I like to use camel case as a matter of style (i.e. I would name it genTableRow) because it can be super confusing to keep track of what’s going on otherwise.)


(defn gen-table-row [js-props]
   (gobj/set js-props "onClick" (fn ...))
   (gobj/set js-props "style" #js { ... })
   (ui-table-row js-props))


agreed with @lee.justin.m on naming for confusion avoidance


I’m i correct in understanding that defining the idents and queries actual creates the graph db schema? Or I mis understanding the first 12 minutes or so of this;t=6s&amp;list=WL&amp;index=1?


@drewverlee what you mean by db schema on this context?


So, not so much “schema” in the traditional sense. the queries and idents define the normalization (which is related to schema)


schema is usually reserved for cases where you talk about more of the explicit data constraints, like field types


An ident says “put instances of this in such-and-such a table, using some column as the index”


that is certainly like schema


CREATE TABLE person (id serial primary key ...)


The query spells out relations, and what properties the component currently “wants”. There is no limit to the props that can exist in an entity in the graph. So, in that sense the schema for props is otherwise completely open


including relational (to-one or to-many) joins that you have “failed” to mention because the component in question doesn’t need them (or they don’t exist)


So, the schema analogy should not be taken past the ident…what table and what is the ID column. The table name has to be a keyword, and the ID can be anything that can be compared.


One way of looking at it is this: 1. You invent some relational tree structure for your UI. Parts of that can mimic (in query form) structure in some data store. 2. You want to run a query, using part of your UI tree structure, to ask the data store for that data (nothing more or less, so it isn’t over-querying). 3. When you get that tree, you want it to be normalized, because that enables easy refactoring, mutations that don’t care about tree structure (don’t need modified when you change the tree), and re-use of the data in disparate parts of the UI 4. When you’ve got normalized data, you also need the query to turn it back into a tree of props, because that is what React needs.


Nothing prevents your data store from having more than you asked for, and nothing prevents your server query handling code from transforming data into a form that makes more sense for the UI.


in fact, a lot of the other code in the library helps enable that, and it’s what pathom library is about: how to convert a graph query into a data store access (whether that be an SQL database, GraphQL, or a call to a REST endpoint)


The more your UI query happens to coincide with server data structure, the easier it is…but there is no requirement for them to have any relationship to each other at all as long as there is some function that can convert between the two.


I think I understand, for a moment I thought the idea was the quries and indents actually setup the graph database. Like the UI asking "I need a person" would create a person structure in the presitant layer


@tony.kay @lee.justin.m - getting closer! Unclear why the gobj/set isn’t working.


@donmullen I see you have gobj/add, not sure what that does, but I think you should be using set there too


just looked up on the docs, add is supposed to receive a js map, as: (gobj/add js-props #js {:onClick "bla"})


@wilkerlucio - add throws an exception when there is already a value. I wanted to confirm it was trying to set it - and it does throw on style - which is there but undefined.


sorry, I read wrong, you are right


so on the logs you see the object without the items you added just on the lives above it?


weird, but one thing to consider, those as js mutable things


so, something else might be changing those objects after you log then


can you try the same example without calling the ui-table-row and see if that changes the results?


Good call. This is in the broader context of a callback from dx-react-grid putting a row in the grid table. I’ve confirmed that it successfully calls - but perhaps something else is going on with the integration with their react components.


one thread…nothing could have the chance to change them


Unclear then what’s happening, though. Was thinking of taking a look at — but seems the gobj/set should be working here.