@dnolen: I tried the om-next-demo-app, but I get assertion errors 500 all over the place. Do you know of a reference-app that I can get up and running? Preferably one with Datomic on the back-end.

Sorry don't have any time to help people with that demo

@hkjels: if you want we can try pairing together to get something going

Autocompleter Input in remotes tutorial code is not updated. I’m using [org.omcljs/om "1.0.0-alpha28"]

@jplaza: You may have success with changing onKeyUp -> onChange. If the input field is not receiving keys this seems to work.

@naomarik: sounds good. I've been putting some code together, but I haven't got anything up and running yet. Should I just share what I have for now or do you want to discuss details and start over?

architectural question. the dom being a function of one flat state atom is a really nice way to build UI (especially with devcards). things become very testable when your components are dumb and just call om/transact! and all update logic happens in mutation handlers in the parsing code. something i’m finding that breaks this paradigm is when something happens and i want to run some logic and then update a query as well as the state atom. now some logic lives in the component to trigger the om/set-query! and the rest lives in the parser behind the om/transact! call. seems like it would be nice if you could have queries that are a function of the state atom instead having to imperatively call om/set-query!.

thanks @griffio ! It worked, I was getting an obscure with core.async though, but it went away after upgrading figwheel to 0.5.0-2

architectural question: I'm creating a login dialog. Trying to log in triggers a remote mutation. How do people handle the case where that mutation fails (due to, for instance, a bad combination of username and password). Do people set a :login/error message in their state atom, throw an alert message, or something else?