om

Please ask the channel first, not @dnolen directly!
pedroteixeira 2017-06-20T00:46:48.244576Z

isn't it wrong that om/transact! returns a map? it looses ordering and actions with same name.. it'd be better if it would return a list of [{:result ..} ..}, no?

2017-06-20T04:27:27.850274Z

@pedroteixeira om/transact! isn't a database transaction; if one mutation fails, it doesn't roll back all of the changes in the transaction. Therefore, there's no benefit to running all of your mutations in the same transaction. If you want to maintain ordering and preserve the results of mutations with the same name, just run them all in different transact! statements. However, you shouldn't have a reason to ever need the result of a mutation unless you're resolving tempids from a remote. If you need the value of something, just add it to your application state and retrieve the value using queries.

👍 1
fenton 2017-06-20T16:22:27.578994Z

i'm trying to implement the simple use case of validating a user by sending a username password combination to the backend. Question 1: should this be a transaction or a query? This isn't information that shows up in the UI, so I thought I could do as a transaction and merge the results into the app-state atom. Should this rather be a parameterized query passing in parameters username/password, and query for a key like :user/authenticated (true/false).

wilkerlucio 2017-06-20T16:40:51.016054Z

@fenton use a transaction to send the the information, if you need to get some data after it use a follow up query, eg: (om/transact! '[(auth/login {...}) :app/current-user])

fenton 2017-06-20T16:43:32.077630Z

@wilkerlucio ok I'll try that. :app/current-user is the query that is occurring in the ?same? transaction?

wilkerlucio 2017-06-20T16:44:27.098862Z

is not on the transation, it's something after it, remember that transactions don't return any data (currently the exceptional case is the tempids replacement, but you should not count on transaction returns for anything else at this point)

wilkerlucio 2017-06-20T16:44:47.106445Z

imagine that you can query :app/current-user at any time, but if the user is not logged in you get nil, otherwise you get the user

fenton 2017-06-20T16:47:12.162918Z

ok. then I guess I'll have to create some sort of token on the clientside to pass through in a parameterized? query, so I can distinguish this user from other users...

wilkerlucio 2017-06-20T19:04:09.432287Z

@fenton well, it will depend on your implementation, but usually this is done with browser session/cookies, so you don't have to do much besides set it on your server side