Fork me on GitHub
#om
<
2017-07-19
>
danielstockton12:07:58

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

assassinduke12:07:55

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

assassinduke12:07:55

done that same error

danielstockton12:07:05

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

assassinduke12:07:09

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

danielstockton12:07:39

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

danielstockton12:07:21

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

assassinduke12:07:52

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

assassinduke12:07:10

second no it doesn't specify the line

assassinduke12:07:40

(about first it gives me an object null)

assassinduke13:07:41

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

jcf17:07:07

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

jcf18:07:57

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

wilkerlucio18:07:42

@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 πŸ˜…

jcf18:07:41

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?!

jcf18:07:44

For real?!!

danielstockton18:07:11

No @jcf, the second part of the ident.

jcf18:07:41

Oh, okay! Yeah I've got the data in the page. πŸ™‚

jcf18:07:10

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.

jcf18:07:48

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.

jcf18:07:42

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

jcf18:07:55

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.

wilkerlucio18:07:26

@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"})]

jcf18:07:06

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

wilkerlucio18:07:18

oh, to fetch idents are good actually

wilkerlucio18:07:27

I was thinking more about mutations

jcf18:07:35

I haven't gotten that far, yet. πŸ™‚

jcf18:07:01

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.

wilkerlucio18:07:01

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

jcf18:07:16

No. The generated query is missing the ident.

jcf18:07:56

This is what's being sent to the server:

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

jcf18:07:08

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])

jcf18:07:44

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.

jcf18:07:14

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

jcf18:07:26

(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}))

wilkerlucio18:07:46

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

jcf18:07:53

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

wilkerlucio18:07:00

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

wilkerlucio18:07:14

had you considered trying #fulcro?

jcf18:07:35

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

tony.kay15:07:55

Not sure why that is defeat πŸ™‚

jcf16:08:48

Defeat in the sense that I'm giving up on solving the problem myself. It feels to me a bit like looking at the answers section at the back of a puzzle book.

wilkerlucio18:07:48

fulcro is the new untangled name πŸ™‚

wilkerlucio18:07:01

data fetching there is much easier

wilkerlucio18:07:07

because it's explicit

jcf18:07:38

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

wilkerlucio18:07:44

no, different people

jcf18:07:48

No that's Adzerk.

jcf18:07:53

Something like that anyway. πŸ™‚

jcf18:07:38

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

jcf18:07:00

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

wilkerlucio18:07:32

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

jcf18:07:29

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

tony.kay15:07:55

Not sure why that is defeat πŸ™‚