@anmonteiro: I think there might something to do with the routing and query. The minimal case I can reproduce is using your template ( latest ), changing the landing.cljs content to. Try to click on the span in nav-ui you will see the error.

Hello, are people using Om.next in production yet?

Giving a nil logger to the reconciler will hide problems, such as warnings (and worse). This won't:

(deftype Logger []
  Object
  (info [this msg ex]
    ; It is pretty hard to get into what's returned so leaving for now
    ;(println "INFO" msg)
    )
  (warning [this msg ex] (println "WARN" msg)))
(def logger (Logger.))

@nxqd: right but your example is not valid

if you don't need a query, you don't need to implement IQuery

@anmonteiro: yeah it's true, but it's just an example of it. In the current app I am developing, I have IQuery in Page of course, but not in NavUi ( actually I don't implement the whole defui in current application, it's just nav-ui defn but both cause same error )

@nxqd: right but the example is not valid so I can't actually see if there's a bug there

I'm not sure what you meant that it's not valid. Regarding the query, you can put whatever you want there, it still causes the same error.

Hey guys

I’m trying to implement local storage caching with om.next

has anyone tried that already? My understanding is that it should be just another type of :remote, am I right?

Also, is not clear to me how server push “just falls out of the design of om.next”, as david pointed out here https://groups.google.com/forum/#!msg/clojurescript/o0W57ptvPc8/qs3y70zSDQAJ

Once I get the data from a push, how/where do I feed it into the om.next framework?

@frankie: 2. just call merge!

@frankie: 1. I'd say it's not another remote, but something your parser / send! function could handle

@anmonteiro: thanks!

finally found a discussion about it https://github.com/awkay/om-tutorial/issues/22

Re: 1, do you mean something like:

(defmethod p/readf :my/key
  [{:keys [state]} k _]
  (let [st @state
        storage (local-storage)]
    (cond 
      (contains? st k) {:value (get st k)}
      (contains? storage k) {:value (get storage k)}
      {:remote true})))

@frankie: for starters, sure

you'd probably need some logic in your send! function to store remote calls too

@anmonteiro: last time I did the debugging, when it first lands on the landing page there is no component path from class App to landing/Home. But when I switch another page, and come back right after that, it does have ( there is no more error ) .

@dnolen: atm reindex! in the reconciler passes the root class to the indexer's index-root

shouldn't we pass the instance so that the index is built with the updated queries (which might have changed in the process)?

@anmonteiro: yes - that would be a bug - would nice to have a test for reindex! functionality to verify it is working correctly

@dnolen: this is what's causing @nxqd 's issue. I can work on this

I'll try to incorporate a test in the patch

I think this would also be related to what @peeja was reporting the other day?

yes likely for anyone trying to transition queries

awesome, thanks guys

If i have a root-component with a query [:a :b] and a sub-component with a query [:a] , should i merge/conj those queries? or should i try to pass the data down to the sub-component as a computed value?

and have no query in my sub component.

I've got a recursion problem that I can't shake. Perhaps I'm doing something wrong... I have a base case with this simple query:

[{:user [:user/name {:user/friends '...}]}]

That always throws: Uncaught RangeError: Maximum call stack size exceeded

In the browser. I've tried different clojurescript versions, different om versions, still always get the same issue.

Anyone have recursion working that can let me know if they ever had similar error(s)?

@bplatz: are you on latest master?

that should've been fixed here: https://github.com/omcljs/om/pull/596

and is not included in any alpha yet

Ahh. I'm on alpha 30

@dnolen: are you able to share the source code for the om-tutorial code that you use to demonstrate om.next and generative testing?

Is there an easy way to do Mixins in om.next? factory doesn't seem to support it. Edit: Nvm, solved it with composition using ui.

@bahulneel: are you talking about the code in this tutorial? https://github.com/omcljs/om/wiki/Applying-Property-Based-Testing-to-User-Interfaces

Has anyone gotten a boot project to work with om using checkout dependencies?

@taylor.sando: are you having a specific problem?

Can I just have a process that watches the om directory, such as fsmonitor and builds using lein install? Then have a checkout dependency in the boot project?

you can do that too yes. starting up lein everytime may take some time though

maybe there's also a lein install --watch kind of thing but I don't know of any

I would assume I'd need an actual boot build file, if I wanted to use something like boot watch pom -p foo/bar -v 1.2.3-SNAPSHOT jar install

@taylor.sando: not necessarily

At the moment I'm doing this: boot checkout -d org.omcljs/om:"1.0.0-alpha31-SNAPSHOT" dev -r to run my project, and I'm using fsmonitor -d src lein install in the om directory. Is this even right?

boot -d cljsjs/react:0.14.3-0 -d cljsjs/react-dom:0.14.3-1 [more ...] -r src/main watch pom -p org.omcljs/om -v 1.0.0-alpha31-SNAPSHOT jar install

@taylor.sando: that should work as well I guess

I'm not getting proper reloads in the project when source files change.

the checkout task just looks into your local ~/.m2 and refreshes files from there if they change

@taylor.sando: ah, perhaps your watch task is after checkout — that would mean the checkout task is only ran once

Ya dev has a watch task

probably safe to take this to #C053K90BR btw

ok

if working with react lifecycle … is there an equivalent om/props but takes the react lifecycle argument vs component

nvm om.next/-next-props

oh double nvm, if I understand the macro its already done for me

in shouldComponentUpdate, there is this:

(not= (om.next/props this#)
                 (goog.object/get next-props# "omcljs$value”))

it looks like its comparing ‘wrapped’ vs ‘unwrapped’?

or am I misunderstanding?

@hueyp: misunderstanding, follow the code path of the props function

gotcha, in my componentWillReceiveProps, the props are equal, but they aren’t here, so digging in

er, the props / next-props

I am still getting hung up understanding integrating remote data into app-state. Has someone build a simple example?

@hueyp: componentWillReceiveProps can't quite be made to work as you might expect

there's an issue about this: https://github.com/omcljs/om/issues/536

I'd say use componentWillUpdate instead

when I try and just implement shouldComponentUpdate inline, I am getting an unwrapped props vs a wrapped props

right, so call Om's should-update?

or maybe I'm misunderstanding what you want to do?

I have some stuff re-rendering, and just want to figure out why. so I am implementing the om default shouldComponentUpdate in my component because I don’t know a better way to inspect the logic

its entirely possible there is context outside of the function I don’t get .. but I just took this and put it in my component: https://github.com/omcljs/om/blob/master/src/main/om/next.clj#L123-L129

@hueyp: that's just not going to work

gotcha

see https://github.com/omcljs/om/blob/master/src/main/om/next.cljs#L744

any suggestion on a way to see what might be causing a render?

e.g. ‘these two things are not equal, here they are!'

it can be hacky

I have an idea, but my limited attempt at ‘componentWillReceiveProps’ did not point to it, but you mention that is not the proper place to look

@hueyp: not from the top of my head, is it following a mutation?

yes

in componentDidUpdate … should prev-props be inspectable?

yes

e.g. just do that instead of willreceive?

or willupdate, as I suggested before

ah sorry

components will be scheduled to render following a mutation, anyway.

i.e. the component which triggered the mutation will be queued

and any other keys that you specified to be re-read

these might trigger the rendering of other components

and the component which did the transact, it will call render even if its a no-op regarding state?

or it still does the normal lifecycle check?

I can check this out, don’t mean to quiz you 😜

time to try componentWillUpdate, thanks!

it is supposed to go through the lifecycle

yah, I do think something is mutated in the props, I just got confused by componentWillReceiveProps which you mention can be out of sync, I bet it was just that

cool

thanks

there must be something deeper causing the update …

(componentWillUpdate [this next-props next-state]
    (let [props (om/props this)
          state (om/get-state this)]
      (println "will update : state & props"
               (and (= props next-props)
                    (= state next-state)))))

they are equal here so nothing I can inspect

@hueyp: (om/get-state) will be the same as next-state

you might want to be calling (om/get-rendered-state this)

https://github.com/omcljs/om/wiki/Om-Next-FAQ#why-is-omget-state-this-equal-to-next-state-in-componentwillupdate

ended up its nil in either case 😜

but yah, that was wrong

I guess I need to look deeper into om to see whats up

like the ‘superficial’ stuff is equal, which exhausts my react knowledge

thanks again for your help!

if I fork om to add some logging to shouldComponentUpdate … would that work? e.g. to print the results of the individual comparisons : https://github.com/omcljs/om/blob/master/src/main/om/next.clj#L123-L129

@hueyp: I just copied the code over from the next.clj file and it works

(shouldComponentUpdate [this next-props next-state]
    (println "from shouldUpdate" (om.next/props this) (goog.object/get next-props "omcljs$value"))
    (or (not= (om.next/props this)
        (goog.object/get next-props "omcljs$value"))
       (and (.. this -state)
            (not= (goog.object/get (. this -state) "omcljs$state")
                    (goog.object/get next-state "omcljs$state")))))

just use it in your component

from shouldUpdate {:id 2, :title “Entry 2"} #object[om.next.OmProps]

so … at this point I should check my om version

I might be copying a more recent shouldComponentUpdate impl

@hueyp: I'm running the latest master

fwiw, unless something has changed since alpha30, this min case suggests to me that shouldComponentUpdate may be returning true in some cases where it shouldn't be: https://www.refheap.com/114181

@cascada-io: will look into that in a bit

@anmonteiro: when you run it locally — are either of your values in the logging output wrapped still? e.g. OmProps

@hueyp: they're not

okay

When using Om.Now with Datascript, how do the components know when to update?

Does the entire UI get re-rendered in the virtual DOM every time the database changes?

@stuartsierra: it’s a part of the transaction, that keys you want to re-read

the indexer knows which keys map to which components and schedules them for re-rendering

DataScript is not really involved I should think

@dnolen: Are you talking about the Om.now transaction or the Datascript transaction?

@stuartsierra: oops sorry you're talking about Om currently

I never tried DataScript with current Om, Kevin Lynagh did get some where with it

yes

you might want to email him for some details about that

for his app he may have been OK with full re-rendering?

or he may have backed away from the Om provided stuff and used Om as React sugar

ah

whatever he did we talked about it briefly and it seems his solution was as simple as he could possibly make it

@dnolen: just submitted a fix for what we discussed earlier today; tests provided, but they were a bit tricky since I had to call add-root! with a nil target, instantiate a component myself and call index-component! manually

but they're passing and the issue seems to be solved

@anmonteiro: ok cool! thanks much

will take a look later

no rush

Can someone tell me how to access an Om defui static field from within a lifecycle method...or just in general?

@tony.kay:

Do you mean a field like a field in defrecord? I didn't think that was supported. I think in om.next you would need to set/get props on an instance of a defui'd thing.

(defui Test
  static field foo 3)

right

then in render:

ah

(.-foo (type this))

ah, that was it...

for the life of me I couldn't think of how to get to the class

duh

why does the doc say fields are not supported? are the docs just out of date? or is that something that works but isn't core to the libarary?

@alasdair: there's no support for fields like in deftype

i.e. (deftype Name [field1 field2])

@anmonteiro: as in instance/object fields? but static ok? Or is it just about differences in syntax?

@alasdair: yes, static OK

I see thanks

@anmonteiro: I was asking about a page with multiple roots the other day. We guessed the way to do this was root + reconciler pairs pointing at a common atom (shared data) is that the "right" way to do it?

i’m running into a “no queries exist for component path" error when attempting to run om.next/transact! during advanced compilation only

i may be doing something silly here, but i’m not sure what it is

Is that a quote or a backtick beside the test-mutate?

d'oh

well, hm. it was a backtick—changing to a quote doesn’t seem to affect the outcome, though