cljs.user=> (om/focus-query '[{:items [:id :type {:comments [:id]}]}] [:items :comments])
[{:items [{:comments [:id]}]}]
cljs.user=> (om/focus-query '[{:items {:post [:id :type {:comments [:id]}]}}] [:items :comments])
[{:items {:comments nil}}]
cljs.user=> (om/focus-query '[{:items {:post [:id :type {:comments [:id]}]}}] [:items :post :comments])
[{:items {:post [{:comments [:id]}]}}]

this makes it seem like union keys should be in paths

but it is impossible for path-meta to put them there, isn't it?

@dnolen: Just want to say hey. I’m a big fan.

@tawus: Thanks, will look into it.

bug for parameterized unions? if the params in Blog's query are removed, the problem goes away

I have a grid UI structure. All the cells are the same Om Next component - and that component's job is to render a checkbox. When a user clicks om/transact! happens. For what is read afterwards (last param to om/transact) I have put in the :id of the component. There are a lot of these checkboxes, and every time one is clicked either on or off, they are all re-rendered. This is despite the fact that only one of them has changed. But it makes sense because they all have the same :id. I tried to put (om/get-ident this) as the last argument to transact!, but that didn't work. Is there a way around this unnecessary rendering?

what happens if you put nothing there?

@tawus: I would rather not use jquery

I’m surprised Om just doesn’t have anything for it.

I guess a plugin would do a lot of good.

@urbanslug: to what?

thiagofm: To show upload progress but again that’s not anywhere near the core purpose of Om

@tomjack: Putting nothing there - good option, and makes sense - this is what needs to be re-rendered. If I put nothing there (in last arg to transact) then the check boxes don't get re-rendered, not right away. But there's an effect waiting, because when I go to say another tab and come back, then the checkboxes become un/ticked as they should be. (And still all get rendered, not just the changed ones). I tend to always put something in the last arg to transact, because I've never seen it work as I think it should, which is to re-render the current component (this) immediately. It is because the component is a (React defined) 'controlled component' (has no state of its own), that it is relying on Om Next.

urbanslug: I think it fits nicely the purpose of separate package/component

@urbanslug: You don’t have to. There are plain javascript file upload scripts too. Even there are html5 based react upload components which are plug-n-play with om

WOW really? hmm let me look into that. I’m quite confused. I haven’t even totally understood clojure.

or at all

@urbanslug: then om can be an uphill task 😬

It is but I am fast learner.

@cjmurphy: transact for me rerenders too much It renders the parent too or atleast that is what seems to happen for me.

@tony.kay: Amazing, thanks a lot! I'm getting an exception when trying to start the server with (go), but it's probably my noobness

@cjmurphy: have you looked into path optimization? If you have idents that should work

@tony.kay: Nice. Just saw the untangled announcement.

@urbanslug: hello!

@dnolen: Hello very glad to "meet" you.

@urbanslug: the same, welcome to the channel

Would migrating code from Om now to next all at once break stuff?

Is it backward compatible?

@dnolen: Maybe I should read the docs more before coming to this channel with questions.

*some questions

Also I noticed the failure to define what a component is in the Om wiki so I went ahead and added one, not sure if it’s wrong because I lack experience with react. https://github.com/omcljs/om/wiki/Conceptual-overview#components

I really had an issue with that.

@urbanslug: not backwards compatible - that’s a longer term goal

well some kind of bridging is a goal

backwards compatibility not a goal

that said, we’ll try to maintain both old and next in the same repo for the forseeable future

True because they are radically different. I hope porting the code won’t break too much. Also I’m thinking long and hard about property based testing for async in Om Next.

But to be honest I’m fearful that it’s too grand a task to take on.

There are a lot of async processes going on in our project and I would like to test them because currently it’s been pushed forward.

migrating a big project is going to be challenging for sure

dnolen: Do you test your async calls?

yes - but that’s not specific to Om

Yes, I understand that. Currently planning on figuring it out with phantomjs. Okay, I’m veering offtopic.

@urbanslug: try porting a huge webapp with jsps, hibernate, and random bits of javascript everywhere to Om and then you'll see how good you've got it 😃

@gary: What about the already huge app that I’m working on though?

Not to mention that I am very new to clojure, cljs Om React literally everything.

@urbanslug: I was just kidding, please don't do what I said because that is what I'm working on

@gary: I am not even familiar with the tools you’re talking about. Tell me about them.

Those are the tools from the Enterprise Java world

So i'm kind of confused about how to structure initial data. Is it supposed to already be shaped like the UI tree when passed into the reconciler or are you supposed to setup your queries and read functions so they read the flat data.

@urbanslug: I'm working on something to help Java EE developers transition to Om so you're not my target audience 😃

@seanirby: Have you looked at IWillMount? Not sure if the same functions in Om Now are in Om Next.

seanirby: You then use cursors to reach into the app-state (i.e the global data map)

urbanslug: im using om next

@gary: WOW uh I have no Java background.

@gary: I am not. No enterprise has touched me yet.

😄

seanirby: Yeah, can’t help you there everything in https://github.com/omcljs/om/wiki/Documentation-(om.next) looks new.

@seanirby: parser :read functions will read from the normalized db and return normalized values. You can use db->tree to convert. Merged novelty should be denormalized and the reconciler will normalize it based on the root query

@seanirby: err, read fns return de*-normalized values. sorry typo

@doddenino: Make sure you follow the instructions on making a config file. The error message for that is better in the next release of server.

cmcfarlen: I thought what read returns depends on your implementation?

@seanirby: certainly, but the shape of the data is based on the query, so if you are using the default normalized state layout, then you can use db->tree as a utility to shape the data.

If your implementation doesn't use the default format, then you have to shape the data in the read fn if necessary

cmcfarlen: I think I follow. Basically use db->tree as a way to convert your query into UI tree data thats in the same shape as the query?

(provided you're using the normalized state layout that is)

@seanirby: yes

cmcfarlen: thanks! im gonna try that out.

@seanirby: there is good info here on parser fn details and responsibilities: https://awkay.github.io/om-tutorial/

cmcfarlen: so if you're doing that, that means you can't rely on Om's auto normalization?

using om’s db->tree goes hand-in-hand with auto normalization, because db->tree expects the db in the om defined normalized format

Hey everyone, I'm very pleased to announce Cellophane, a server-side rendering library for Om Next. Check it out in the link below, and don't hesitate to ask any questions. https://github.com/ladderlife/cellophane

@anmonteiro: path optimization seems to be for when there's a speed problem, which I don't have. I want an object to be re-rendered rather than a class. Are we supposed to be able to put Idents at the end of a transact call? It is definitely the case that 'other things' are effected by the mutation, so I do actually need to use the 'last param' of transact call (i.e. can't rely on the query).

@cjmurphy: yes you can use idents at the end of a transact! call

if that doesn't work it's a bug, I've seen it work before

Thanks

@anmonteiro: this looks like almost a total fork of om, is that true? https://github.com/ladderlife/cellophane/blob/master/src/cellophane/next.clj

@jlongster: definitely, we need the same kind of behavior in the JVM

it's something that could eventually become part of Om

@anmonteiro: yeah, seems hard to maintain, but nice work! When I was working on my app I just use CLJS on the backend as well

@jlongster: well you can definitely use React's renderToString then

this is targeted at people using Clojure in the backend

definitely hard to maintain for the time being

probably more than foam since Om Next is still in active development

@anmonteiro: makes sense!

nice to have for others I'm sure

@anmonteiro: looks useful, might be nice to start a wiki page of things that would need to be done to fold that in that I can review

@dnolen: Dully noted, I'll get to it soon. This is mostly based on the Foam concept

nice

lots of things will be the same

But I've built on it to generate markup that React can pick up on the client!

I’m pretty much 100% behind the Foam thing, esp. now that react-id is history

FWIW, Cellophane still generates reactids

(still) à la React 0.14

to be expected

yes

I'm quite proud of the fact that it can generate markup which React picks up on the client side

some reverse-engineering was needed there, attribute order, supported attributes (camelCase stuff, etc.) and other stuff

and, when everything was sorted out, still needed to wrap everything in an extra div or the checksums wouldn't match

crazy stuff

@dnolen: there are also some hacks in Cellophane in order to support Om Next statics... ATM I'm creating Clojure records for components and multimethods that dispatch on those classes for queries, params and Idents. I resorted to this approach because I couldn't find a way to have static methods in defrecord Any alternative suggestions are deeply appreciated

yeah there’s just no way to do that in Clojure

static methods

creating Clojure records (which generate Java classes) also introduces the limitation of having to use :import in the ns macro

:require is not enough

yes if you want to import the record directly instead of a factory fn

yes, it was necessary e.g. in the TodoMVC example

where you (get-query todo/Item) which is in another ns

(for context: i've added that TodoMVC example as a full-stack example with server-side rendering to the repo)

hrm right, yeah something to think about

anyhow, I'll work on some design doc in the next few days and add it to the wiki

cool, thanks would be helpful, thanks

@anmonteiro: awesome work with SSR!