@dnolen: fixing #604 depends on the #637 fix. do you think it’s OK to put them in the same PR?

(I do provide separate tests for each of them, though)

@dnolen: looking through the issues, I think these have been fixed and can be closed: https://github.com/omcljs/om/issues/673 https://github.com/omcljs/om/issues/679

@anmonteiro: k thanks

Just thinking out loud, it's not a bug for me, but I noticed a change from alpha37 to alpha40, which is that a map I pass into factory:

(.root render.
((om/factory Component) {:data "to be read in comonents props"}))

ahh ok, one big difference, besides version, is that I use om/update-state! in componentDidMount, that causes this more likely than version changes. Nevermind.

@anmonteiro I saw that you set up om/transact! to return the parsed value in alpha40, did you have a use case in mind for that? Since the app will have to re-render the component with the new data anyway, I’m not understanding the benefit, but I feel like I’m missing something

@ethangracer: when a mutation throws, the error will be assoced in the result

Previously there wasn't a way to get at those stacktraces

So you could only guess what was throwing

ahhh, yes that will be very handy

thank you

@anmonteiro: mapped-ident??

I'm assuming this is a function that checks for the existence of an item in a table via something that looks like an ident

so, an "ed" ending seems better than "able". Though you may feel that the mere existence of the table is sufficient. In which case "able" is better.

@tony.kay: thx for the feedback. Atm I'm just checking for the existence of the table

It seems to me that the actual item may exist or not depending on remote stuff but the table will be there if any other items of that kind have existed before

@anmonteiro: yeah, that's reasonable. If the table is there and the thing checks out as an ident (2-vector starting with a keyword) then it should be a rare case that you get a malfunction. Especially if people use the idiom of naming tables things like :people/by-id instead of just :people...the latter leading to possible false-positives when composing random libraries of components.

@tony.kay: agreed. IMHO, sometimes stronger validation leads to less usability