@mattyulrich: why not just create the ident with the id you have set as a value? and then get the value from the event like this (-> e .-target .-value)

But the value is a number, I can create the ident from that like [:class/by-id val] but once I have that, how do I extract the actual item from the db?

If you set :selected-class to [:class/by-id val] you should automatically get back the new selected class because you call om/db->tree in your read function for selected-class

@mattyulrich: fixed it for you

Ok - you’re right! When I did this before, it didn’t work because my id was coming in as a String, not a number.

see answer in your gist

Yeah.. Ok, that works great.

So - where is my id being converted to a String?

@mattyulrich: when you get it from the DOM node

it comes as a string

the option’s value property is a string

Ahh - ok, that’s a fundamental bit that I never put together before.. Thanks for the help!

I’ve inserted comments where I changed things

other thing you got wrong was having queries where they never made it to the root

I just removed those

Yup - I see your changes, I had something like this at some point but when I set the [:class/by-id val] it wasn’t doing anything because the val was a String..

@mattyulrich: other thing. if you notice, I’m using (.. event -target -options -selectedIndex)

depending on the browsers you’re targetting, this might not be the best approach

Yup

not every browser implements it, AFAIK

the other option is filtering the options for the one that has the selected property set to true

would it not just be good enough to use …. -target -value ?

@mattyulrich: pretty sure target value is not a thing in the select

btw, what you wrote in my gist with the computed props in the Class-Select really clarifies things for me… I’ve been really confused about where I need and don’t need to put the IQuery on my component.

or at least the thing you want

Ok - this was really helpful; thanks!

target value is definately a thing in select and works in every browser. It returns the selected value as a string

Ok - thanks to all the help from you guys, I’ve updated my gist here: https://gist.github.com/mattyulrich/8524ce8f20606e644770205021875639

Everything works exactly how I think it should and I have a much better understanding of how om.next works.

I added in the simulated ajax calls to login and get the data associated with the user… so my initial app state now starts as an empty atom.

And cleaned up some more places where I really didn’t need an Ident/IQuery (around the Header bits; it’s much cleaner now)

In my mutation functions, I was able to perform the mutations from raw “server” data by using om/tree->db and merging the results into the state. It seems to work great and makes sense to me, but is this an idiomatic approach?

Anyone else think that the om parser would make a good separate library? It could handle api calls really well, especially calling different services and being able to reconcile them into a single response map at the end. One addition might be the ability to do async calls, like having a top level timeout that will run the parser until the timeout stops, and then return what it has up to that point.

@taylor.sando: atm the parser is very tied to the Om Next query grammar

what do you have in mind for relaxing such assumption?

I like the grammar as it is. It would be more about the implementation on how the parsing itself would be run

Could potentially be useful for om itself, if you wanted to guarantee 16ms parser times.

@taylor.sando: I like the idea having heard it just now. I also wonder if that couldn’t be a part of Om

i.e. why a separate lib?

I guess because you don't really need the reconciler and view logic if you wanted to use it simply as an API handler--though om isn't exactly large, and if it's on the server, I guess the added source code doesn't really matter.

@taylor.sando: that’s the reason of my question. code size doesn’t really matter on the server

atm anyways, Om on the server is just the parser implementation and the transit handlers

I guess it would also be separation of concerns. I like the om query syntax as an answer to graphql. It's a good message query syntax, especially when combined with transit.

@anmonteiro: really loved your talk, just watched it 😄

is there a link to said talk?

@blissdev: See in @anmonteiro 's Twitter: https://twitter.com/anmonteiro90

@andrewboltachev: thanks!