I think the problem is the om/build-all, try wrapping that in a dom/div.

i am not so sure because i was getting the same error before even adding that part but i will try in a sec

done that same error

What about (dom/p (:first state)), does that not need a second nil argument? I'm sorry, no longer familiar with om.now.

Hmm it may be because i think it tries to make that text a class

let me check

dom functions accept two arguments (attrs and children). Anyway, the error suggests render is returning something bad.

Do you not have a line where the error is raised?

first adding nil doesn't help but i think it shows that there is something really wrong with the code

second no it doesn't specify the line

(about first it gives me an object null)

wow programming at its finest after a restart the object null disapears

All those idents of [:email/by-id nil] look great when calling cb in my send fn.

Hmm. I think I may have been normalising things myself right before om.next would normalise, so double normalisation. 🙂

@jcf make sure the attribute you are using to form the ident is listed on the query part, I personally had trouble with this a bunch of times 😅

Oh wait! So my om/IQuery should include the attribute in the om/Ident? So where I'm using :email/by-uuid I should really be using :email/uuid because that's what's in the query?!

For real?!!

No @jcf, the second part of the ident.

Oh, okay! Yeah I've got the data in the page. 🙂

Problem now is the query generated by om.next and sent to the server doesn't include the ident, so instead of something like {[:email/by-uuid UUID] [:db/id ...]} being posted, I'm getting just [:db/id ...] and that can't be read.

I'll have attributes shared by entities for sure. I guess I'm supposed to use a hash map in the query instead of relying on the ident feature.

So my query in the detailed view should be {:email/details [:db/id ...]} because idents don't work the way I think they do.

But then how do I know the ID of the thing I'm supposed to return… you can't just send a list of attributes to the server without some kind of ident.

@jcf keep in mind that idents are mostly a way for you to normalize your data into the database, when communicating with the server is better if you send everything you need as parameters, something like ['(my/mutation {:db/id 123 :user/email "blabla" :user/whatever "foobar"})]

So to fetch email 123 from the server you'd use IQueryParams?

oh, to fetch idents are good actually

I was thinking more about mutations

I haven't gotten that far, yet. 🙂

Right now I have a list page that pulls summary info, and I'm trying to get a details page per item that will pull more detailed info.

but you have to parse this on your server-side, aren't you getting the full query there?

No. The generated query is missing the ident.

This is what's being sent to the server:

["~:db/id","~:email/body","~:email/sent","~:email/subject","~:email/uuid"]

For this query/ident:

static om/Ident
  (ident [this m]
    [:email/by-uuid (:email/uuid m)])
  static om/IQuery
  (query [this]
    [:db/id :email/body :email/sent :email/subject :email/uuid])

I was expecting the generated query to include the ident automatically but maybe I need to write a custom :remote spec in my read method.

Not sure how I'll get at the props for the email though. The env doesn't contain that, and props is nil.

(defmethod read :email/by-uuid
  [{:keys [query state ast] :as env} k props]
  (let [st @state]
    {;; :value (om/db->tree query (get st (:key ast)) st)
     :value (get-in st k)
     ;; :remote (update-in ast [:query] #(into [] (remove om.util/ident?) %))
     :remote true}))

one thing to notice, the pure Om.next way of handling data loading is tricky IMO

I'll have to replace true with something like {[:email/by-uuid UUID] (:query ast)}.

trying to make diffs and having to put markers on the parser

had you considered trying #fulcro?

No, but I have debated admitting defeat and just using Untangled.

fulcro is the new untangled name 🙂

data fetching there is much easier

because it's explicit

I see. That's from the guys who built Boot?

no, different people

No that's Adzerk.

Something like that anyway. 🙂

Server-side rendering is on my todo list. Maybe I should use Fulcro instead.

Evaluating the right JS to get Nashhorn ready to render is tedious at best.

I highly recommend trying it, dealing with pure Om.next is like trying to write a web-app without any framework, Om.next is more like building blocks then a ready-to-use library

Thanks for the tip, Wilker. I'll take a look.