Yeah, I definitely haven’t thought through the consequences of these decisions. All I know is that I would like some way to promote a query from a union heh.

I will probably end up wanting the same, so I'm happy to keep banging heads on it

Ok, well I have to run right now but I read everything in here and I’ll probably be back on later tonight.

ok. I'll give it a bit more thought as well

Cool, thanks for talking this out with me

welcome

@noonian: FYI, I just wrote a test that unions themselves can be promoted to root, and that works. Since unions can imply a one-to-many of heterogeneous type, the server would need that info in that case. So, promoting something deeper would have to imply that there is only one.

As per my early error inquiry, it was caused by re-definition of the reconciler however I'm not sure why, as I re-define it when I swap out different om-next apps during normal course and that works fine. Changing the reconciler to defonce solved the problem for now. FWIW.

This has to do with figwheel reloading the file my reconciler is defined in, along with my core namespace.

@tony.kay: Thank you so much for awkay. Really excellent!

er, is there some lein template to start off on om.next?

@tmtwd theres a really outdated one

Can't confirm if it works

now that i try to search for it I can't find it. It's has an indian name...

jannis has a boot template though https://github.com/Jannis/boot-template-om-next

hi guys I try to build a very simple tab component in om next, but the view doesn't change when I mutate the state: https://gist.github.com/rhacker/af34b460e149001b3a06 . Any suggestion would be great. thanks

@jethroksy: https://github.com/priyatam/mala ?

@ianchow: yup that's the one

@tony.kay: the potentially outdated information on your wiki page (huge kudos for that btw!!) are the union queries. as @dnolen pointed out, queries MUST be vectors

Can you use Om if you never have learned react as a beginner. and if so, what tutorial or book it then the best one to learn as a beginner

This is what my search turned up: https://awkay.github.io/om-tutorial/#!/

@cjmurphy: thanks

a colleague asked me to build a little app to upload some CSVs with parking spots data and a JSON with a k-nearest-neighbors clustering model to visualize the clusters by color on a map, and it took me exactly one day with om next, client-side only, and getting stuck many times. Now I could build it in a few hours! The more you get about om next it’s scary how fast you can develop stuff.

wow, cool - would you mind sharing some code ?

I’ll ask the CTO if I can open source it — there’s nothing sensitive really

https://github.com/advancedtelematic/parking-visualization

feedback is more than welcome — I’m still struggling with many concepts in om.next

I've read recently not to use core.async in your UI...I'm using it and it seems to work fine, and seems reasonable for what I'm using it for which is distributing input events (mouse, keyboard) via pub/sub

what's a bad idea about this ?

@txus: cool stuff, one question though

why did you define this add-normalized-resources fn?

can you not use tree->db instead?

I figured, when new data comes in, I need to normalize it myself

oh

uhm lol

didn’t know about tree->db

ok that answers my question 😄

maybe try with it, should simplify the code

that’s great!

😄

thank you

and probably add-normalized-resources doesn't work for all cases

now I'm just nitpicking and you probably know this, but :normalize true is only needed when you pass an atom to the reconciler

ah yeah

even style critique is very useful to me atm, I’ve seen a few different ways to do things and I’m open to adopting the better ones!

Om Next kanban demo updated to alpha26. Thanks to om/db->tree the reads are much simpler now: http://jannis.github.io/om-next-kanban-demo/

@octo221: you just need to be careful when pairing core.async with React since core.async go loops are stateful resources

@roelof: you can learn Om though I wouldn’t say it’s the best starting point for people just getting into ClojureScript. It is important to grasp React fundamentals

@nblumoe: union queries are the only exception to this rule

@nxqd I would try to get that working outside of devcards first

@dnolen: any tips how I can learn the reacyt fundamentals as a beginner

@roelof: there are many online resources on React now, just go through the Facebook material

@dnolen: ok

I see there are functions like :item/by-name or :item/by-id . Are they some magic functions defined under the hood ? ( in queries )

@nxqd: you should go through the "Components, Identity & Normalization" tutorial

it explains what you're trying to grasp

@anmonteiro: thanks (y)

@nxqd: btw if you can't get your state to mutate in devcards, try transact!ing directly on the reconciler and not on the component

yes, Looking through how the wiki is written, I can see that there are many methods we can debug and use to add test without interact with the component, very nice 😄

@anmonteiro: ah, btw on the tab example above, I can mutate the state of component but the view doesn't seem to update accordingly. https://gist.github.com/rhacker/af34b460e149001b3a06

then try without devcards as David mentioned

woa it works -_-

thanks @dnolen . Is there anything wrong with devcards ?

@nxqd: there is yes, you have to be very careful

I can’t remember if @bhauman has fixed the state issue yet

awesome, it's good to know Thanks for great work

the best thing ever I have seen on frontend development

Hmm. I'm on [org.omcljs/om "1.0.0-alpha26"], and om.next/query->ast is evaluating to nil

om.next/factory is a function, though

and evaluating om.next/query->ast doesn't give me a WARNING: Use of undeclared Var (which I get from om.next/foobar)

It acts like it's actually defed to nil…

Does that ring a bell for anyone?

make sure you've cleaned and rebuilt. You'll get all manner of madness if you don't

on a version bump

Ah, maybe that's it

Just ran lein clean and re-ran Figwheel, and I get the same behavior. Odd.

#'om.next/query->ast evaluates to the var without an error, so there's definitely a var there.

Bizarrely, it even has the correct metadata…

@dnolen: :watch-atom false prevents rendering on atom change

@bhauman OK great, will have to try that out

and update my own cards so that people understand the pattern

@dnolen: it will re-render after a compile though, to pick changes

right that’s fine, can use the atom to persist state like people normally do

@dnolen: I was also thinking that you can put the whole reconciler in as the init-data param as well

something to play with anyway

wow there are there are a bunch more docs in the om next wiki

We've been busy :)

yes you have!

Aha! That was silly of me. lein clean did nothing, presumably because I'm using Figwheel from a script, and not from lein

(It's my first time running it that way)

@peeja: you have to tell lein clean what to clean. Figwheel is not involved script or otherwise.

Oh, really? I wonder how I have it set up on my other project, then. I thought Figwheel injected its list of clean targets.

Probably something set up long ago and buried in config…

You will probably want something like this in your project.clj:

:clean-targets ^{:protect false} ["target"
                                    "resources/public/js/compiled"
                                    "resources/public/devcards/js/compiled”]

@noonian: Thanks!

np!

what is people’s experience transitioning an app from om to om.next?

tmtwd: I’m planning the transition out now, with the hope of starting in beta

om.next is not in beta yet?

nope, alpha 26 was yesterday

oh okay

long story short: I think I can do the transition piecemeal

interesting

are we supposed to be able to transition piecemeal or is it expected we write the apps from scratch?

I can’t speak to that

this is a larger app with a lot of shared components and behaviors

and I tried to stick to react-isms (ie component state vs. app state) when possible

interesting

are there any good comparisons of reagent vs om?

feature wise etc

don’t know of any

it feels like reagent tries to abstract away as much of react as possible

while om.now is more of a thin layer over react with a bunch of extra features

thats how I experience it anyways

both have immutable data structures and use global atoms to manage state

as far as I can tell

I think they have very different scopes. IMO Reagent is more like a thin wrapper around the rendering part of React. It de-emphasises the react component lifecycle and emphasizes readability by defaulting to hiccup syntax. I don’t like how Reagent does change detection though, it uses macro magic and special atoms to update when data changes so I think you either have to use discipline and do things like single atom app state out of convention or you can end up with something that is hard to reason about. Om next is really trying to solve a lot more problems at once like server communication, data duplication/inconsistency on the client etc. Om next is tackling the issues that Falcor and Relay are as well as wrapping React and integrating it into a streamlined package.

true

@naomarik: There was some discussion about the two on reddit: https://www.reddit.com/r/Clojure/comments/3vk58p/a_rant_on_om_next/ - a good bit of cruft to sift through but some good observations as well. So, reddit.

@tmtwd: what are the extra features you find worthwhile?

@naomarik: It isn't really about features. It's about overall design. The features fall out of that. As engineers we're often way too concerned about features. If that is your criteria, you want Angular. Look at all those features! Form support, libraries, plug-ins. Wow a cornucopia! Om next is about simplicity: Move the complexity out of the UI. Eliminate complexity where you can. It is a "Simple vs. Easy" kind of project. That said, it can also be hard, in that you and your team have to understand higher level concepts to do it "right". You work turns into more thought, less typing. I'd recommend watching David's most recent talk on Om next at the conj, and concentrate on his first few slides about the goals. Features is not one of them

thanks for the insight @tony.kay 😉

i'm just stepping outside of my rails cave into this world, there's a lot to learn and options to consider... i watched the first 20 mins of the talk a few days ago and i got a bit lost

but i have a bit more knowledge now it might make a bit more sense

There really isn't much of a comparison to Reagent...they are approaching the problem in a totally different way. Lots of ppl are totally productive in Reagent. Lots of people like it. I have a team of 9 working on a product in Om next. There is a lot of "changing the way you thing about the problem". But, my team is confident that the long-term has good implications on maintenance and support, because, as Rich says, your ability to reason about your code is the most important factor in being able to deal with it in the long term. If you're doing quick one-off problems, do whatever is easy for you. Om may or may not be that....

the fact that they use React underneath is about the only similarity

Jafar Husain has some good talks on Falcor that might help understand the ideas behind the server communication and links/idents ideas in Om next. Om next also takes the co-located query idea from Relay, although I haven’t explored Relay as much as Falcor so I can’t recommend any resources personally.

also this talk by David and Kovas Boguta: http://www.infoq.com/presentations/domain-driven-architecture

I'd recommend reading the intro docs to Relay...they are short, easy, and help a lot too

particularly "Thinking in Relay"

and realize that there will be more up-front work in getting started with Om than something like Reagent. Reagent is trivial to learn...Om takes more effort.

long term benefit vs short-term cost

@tomc yeah I do not recommend reading through that Reddit thread

the quality of discussion there is depressingly low

i suppose both are nice to have, i've essentially been able to jump into reagent knowing nothing about react and having just gone through some clojure tutorials to prime myself on the language and get something nice working immediately which is pretty gratifying.

@dnolen: I posted on reddit looking for help finding an apartment in an area good for dogs and it turned into a discussion on how I'll be incapable of raising children, so the fact that that discussion didn't devolve into personal attacks was good enough for me.

lol

@naomarik: as everyone has said, reagent is quite nice and I nor anyone else here should deter anyone from using it

yeah @dnolen, im just asking questions trying to suss out the long term benefits om may provide me

if Om Next seems to solve the problems you care about then it may be a better fit

i'm watching you talk right now 😛

but the choice should be based on your problems, not what randos said on the internet

I think yogthos always discusses things with a level head so I liked what he had to say there. Whether any of it will help with the Reagent or Om question is another matter.

yeah yogthos is worthwhile to read up on

I quite like reagent for smaller project…. I use om for everything now though

i had no idea about the data access queries as opposed to rest,.. that's absolutely massive

what do you guys think of service workers? https://medium.com/google-developers/instant-loading-web-apps-with-an-application-shell-architecture-7c0c2f10c73#.vx36yipf0

@naomarik: depends on the use … but for a particularly cpu-intensive thing in our interface we actually got much better response times with websockets to the server and running that code there

I'm running into a weird issue: I'm following the Remote Synchronization Tutorial (https://github.com/omcljs/om/wiki/Remote-Synchronization-Tutorial), and when I get to the end and try to run the autocompleter, I get Uncaught ReferenceError: ReactDOM is not defined

But react.inc.js is on the page…

I have a breakpoint on var ReactDOM = _dereq_(35);, and it does appear to be setting ReactDOM…

Oh. But that's var ReactDOM, not window.ReactDOM.

So, anyone know what's support to export ReactDOM to window (using cljsjs/react-dom)?

https://twitter.com/anmonteiro90/status/675051435512504320

You will get that if you are trying to use sablono or something and not requiring om.dom. If that is your problem you can work around it by requiring either om.dom or cljsjs.react.dom

Oh, of course! Thank you!

That makes sense.

Np!

So, I posted what I see as an async problem in the reasoning model of send: https://github.com/omcljs/om/issues/534 This problem only happens when auto-normalization is on, but it can be summarized as: - Send a query off to the server - Time passes - UI interaction changes the query - Server response arrives - Callback normalizes against the NEW UI query, possibly losing data if that portion of the UI isn't currently in the UI query (say because it has been "routed" away) The workaround is to turn off normalization and do it by hand (using a query of your choice and tree->db).

Not sure if this is a sensible question, but: Is there a reasonable way to build an Om Next component tree and reconciler, and then mount it inside a larger React app? Basically, I'm looking for a way to make a small piece of our Om.Now app use Om.Next, to try it out and find bugs using a non-mission-critical part of the app (and eventually to expand as our migration path).

@tony.kay: agreed it’s a problem, some enumeration of possible solutions welcome.

@dnolen: The only suggestion I have is to memoize the root query from the UI inside of the callback generation. The send that "receives" that callback only has queries in that context, so it seems like it fixes the reasoning. I don't see any problems (other than code wrangling) with that approach.

Although we may find other subtle sequencing bugs in the same place...seems like we might end up wanting some kind of queue around sends so we can reason about them in order, even if there is out-of-order response from the server

@tony.kay: why do you need to memoize the root query?

to me the bug is that the query that was used to fetch isn’t used to normalize

right, and remembering the query is the solution I'm suggesting

but this isn’t about the root query

it might not be a root query

ah, I see your point, though currently the callback does normalization with the root query

or did I misread that

line 1348

next.cljs

sorry wrong line

1321

I dont get the thing with links in the query to work. I’ve tried my own code and when that didn’t work i tested with the appendix code from the wiki page ”Thinking with Links” but I get nil for current-user. Using alpha24. Can anyone help me?

@snichme: working for me, be sure to clean your build

@tony.kay: right I would consider that to be the bug

send probably needs to take the original query

er excuse me I mean the callback

[response query] should probably be the callback signature

due to the laxness of JavaScript this means existing code won’t break and people can incrementally fix

but actually I think it’ll just have to be a breaking change since it effects merge

but not a big deal IMO, current behavior is just a glaring bug and we’re still in alpha

@anmonteiro: and by clean you just mean

lein clean

lein clean will only get rid of whatever lein knows about, you can configure :clean-targets in your project.clj. You will probably want to get rid of target and wherever you are generating your js and out files to.

okey, will try that

I’m very new to Om. With queries in Om Next one can communicate with server. But how do I manage UI state, which needs to be mutated only locally?

@roman01la: IIRC https://github.com/omcljs/om/wiki/Thinking-With-Links%21 answers that

@dnolen: Yes, that would work, given that send does know the query...the query is already available there.

it probably never really makes (safe) sense for callback to automatically decide to use the root query

@szx: thanks

I'd be interested in what others are doing about UI state. We decided (so far) on a couple of add-ons that seem to work for all of the cases we've seen so far: 1. We namespace properties that need to be complected onto data that came from a server using a ui prefix (e.g. :ui/checked) 2. In send, we use clojure walk to strip these out of the query before sending to the server 3. We use a deep merge for merge-tree, so that we don't stomp on UI-related props that might have been on things we're updating from the server. 4. We also have an algorithm for resolving the problem of properties disappearing over time, which the deep merge might accidentally leave around. Basically, we use the query to understand what we asked for, and if we don't get a response for that property then our deep merge removes it as a post-processing step.

That's basically what we've done (in a less sophisticated way). I've been trying to think of a good way to keep ui state completely separate and sort of "zip" them together upon query, but I haven't found a satisfying way to do that

Sounds reasonable, I've used a combination of 1-3 so far.

About 2 - wouldn't it be possible to strip the UI props from the AST for the remote in read?

That's probably what I would do

@jannis: walk lets us separate the concern in 2, and not repeat it all over the read code

When you do a set-query! on a component, a read is performed on that component’s query. Do you think it would make sense for the env of that read to have a ref if the component ident??

@jonsmock: In my app sample in the tutorial I originally did just that, but I settled on this latter method because separating the data caused other problems. Not saying it cannot be made to work, but it ended up being easier to just maintain them with the objects.

I am playing around with loading data incrementally, and it seems like it would be useful to have that ref for forming remote queries

the primary problem was the zipping made db->tree less useful

@tony.kay: Right, I see. Another idea could be to do (def parser (om/parser {:read (comp strip-ui-props-from-remotes read) ...})) but that's basically what you do, except as part of send. 😉

@caleb: Terminology...what do you mean by ref...that term gets thrown around loosly

@tony.kay: You’re right. The ref in the Om sense [project/by-id 2]. When you run transact on a component that has an ident method, the env in the read function has the Om ref of the component that you called transact on

ok, so the term is ident, not ref. An ident is a vector of two with kw as first ele

ident is also the name of a method

@tony.kay: Hmmm, yeah. Did idents used to be called refs? Because if you do run a transact on a component, you do get a :ref key that has an Om ident

I take the blame for that

so, yeah, as David says, there was some naming convolution (and some may remain)

@caleb: not sure about :ref as a result of transact.

even if it isn’t you shouldn’t be using it

@dnolen Okay. https://github.com/omcljs/om/blob/master/src/main/om/next.cljs#L816

@caleb in general if something has been written down somewhere you should avoid it