How can :db/id be a valid/working :keyfn when the record doesn’t have such an entry (the record is {:person/name "Sam”})?

@tony.kay: Thanks for the help. I can’t find anything so far that would explain the slowdown in one case but not the other. I see that @dnolen mentioned in slack a Safari bug that caused Om.next to be slow, and maybe that’s what this is.

It doesn't affect production CLJS. It's a Safari bug. Not worth addressing.

Apple is aware of it.

If you can actually repro in advanced I will be very surprised. We hear a lot about Safari. Make a minimal case if you think it's really reproduceable. It shouldn't involve Om though if possible.

@dnolen, This may not be the same bug then because it happens regardless of :optimization settings. This is the project that will show the problem depending on the order that you “load” the statements: https://github.com/caleb/om-input-perf-example/blob/master/src/perf/core.cljs

But yeah, it’s only a Safari thing, and unfortunately I’m clueless about what to do. I really just want to make sure I’m not doing something stupid in my code.

That's not very minimal, sorry not going to look at that.

Fair enough

Nothing but the reproducer.

I can boil this down even more to just show the slow case, thanks.

Hello all! The quick start mentions including {:value {:keys ...}} inside a mutation. My question is that if you have that on a server side mutation, does the keys vector tell the client side to update those keys? And if so, does this happen automagically?

anyone built an om next app that does server-side queries and have it on github? I found https://github.com/Jannis/om-next-kanban-demo but it has no remotes

https://github.com/Jannis/custard/blob/master/src/custard/sente_bridge.clj#L50 - reading only https://github.com/Jannis/copaste/blob/master/src/server/parsing/copaste.clj - reading and mutations using a somewhat esoteric data store

@jannis sweet thanks! (I'm considering using a sqlite backend right now. maps well to my data and easy to setup. still not sure how to map queries to it yet, but still learning. I'd be fine to only supporting limited types of queries)

And the tutorial on https://github.com/awkay/om-tutorial/blob/master/src/main/om_tutorial/simulated_server.cljs has a simulated server (wired up as a remote - it doesn't really matter whether that's a real remote or not).

@jlongster: Any db should work, really. Relational db tables can be mapped to maps with property name / property value pairs trivially, that's close enough already. You may have to translate query expressions to SQL (particularly for joins and recursion) but the query syntax is fairly simple. Or instead of translating ~1:1 to SQL you work out what SQL queries you'll need to run in a more coarse manner, translate the data to nested maps and let Om's parser do the rest of the querying.

@jannis: yeah, worst case I figured I'd do the latter. either way will be a fun experiment. that's one thing I like over falcor/relay: seem straight-forward to map to whatever backend I want.

Indeed.

I've probably used 4-5 different backends in different experiments so far. I do find the server side is lacking a bit compared to the coherent client story that Om next provides. Even with neat tools like the Om Next server-side parser, Datomic and perhaps push updates from the server via something like Sente you end up juggling a lot of pieces around.

@jannis I don't see the remote reads in custard; why is there no remotes key here? https://github.com/Jannis/custard/blob/master/src/web/reconciler.cljs#L84

@jlehman: There's only one remote in this case - :remote.

oh I see, thanks

It's the default in Om Next. Return :remote true from a client :read call and it'll be sent to the one remote using :send.

oh, gotcha

thanks!

yw

hopefully this is the last big conceptual piece I need to get over, and I can start building something and give better feedback

Good luck!

@jlongster: it seems you might need to read the source code in this stage of the development 😄 https://github.com/omcljs/om/blob/master/src/main/om/next.cljs#L1730

I've read it a bunch, hadn't seen that yet though

hi guys how to define custom component function in om and how to call it ?

(defui
  Object
  (custom-fn [this] ...)

@codonovan: awesome. thanks

@tony.kay: so my question about your PR is why you consider things with parameters not mergeable - is this because of the non-determinism of which parameter map wins?

Hey David...sorry for the delay. How would you merge this: [(:a {:x 1}) (:a {:x 2})]

assuming two different paths have re-roots to the same top-level thing

but each have parameters

@dnolen: ^^^

@tony.kay: right that’s what I was saying

Perhaps it would help to be more expansive: [{:j [(:a {:x 1})]} {:j2 [(:a {:x 2})]}]

seems like an edge-case at the moment - would like to hear from somebody that actually needs it

if both re-root, you cannot merge them, since the parameters are different

yeah, so while you could write a parser that would result in that, it should be considered an error

however, the PR fixes the case where the re-root contains params...the current process roots strips them by mistake

right but I can imagine various ways to handle this - but again rather see that driven by some actual need

merging the PR

ok. Yeah, I think if the parameters are identical it is fine...agreed that finding a real use-case should drive further dev.

@tony.kay: that closes OM-545 right?

union support is still pending...Noonian had done some work on that

His patch was fine for re-rooting, but I don't think it was right in terms of merging...there was no test at least

I think you closed that PR

@tony.kay: https://github.com/omcljs/om/commit/5b5a6b0e3af2c01cd60fc154b5e3f9fd1166e3e1

was merged

@dnolen: No, I mean you closed the one from noonian that added union support

https://github.com/omcljs/om/pull/547

Yeah, I haven’t done any more work trying to get unions working with process-roots

At one point I worked around that issue by representing routes with one join per route

@tony.kay: ah right, it wasn’t clear to me that the PR addressed the problem

Hi. Here, in 2nd sinppet https://github.com/omcljs/om/wiki/Components,-Identity-&-Normalization#adding-reads are '[:name :points] just for documentation purposes? I mean in this particular case. For me it seems that it isn't ever passed to read-fn, and get-people is doing all the job for deciding on whatever fields would be passed to Person component. Would read-fns in the future accept trees (say, {:list-one [:name :points]}) as a key, instead of single keys, or is that wrong thinking?

hi all. any recommendations for image dropzone or fileupload components in om?

@btking: why not dropzone itself? or, e.g. plupload

if there's library already written, it would unlikely be easy to write suchlike one from scratch just to adopt to Om

(and what that ever means?)

tried dropzone, couldn't get it working correctly. none of the success callback stuff rendered (ie thumbnails)

if that makes sense

I wonder if you can share you code somewhere

So we can take a look at it

Interesting, if it doesn't work 'cause of integration with Om or for other reason

You might have to “touch” your components to cause a re-render. An easy way to test that is to just call add-root! again the same way you init the app.

here is the code

(defcomponent image-dropzone [data owner {:keys [url]}]
  (render [_]
          (i/input
           {:type "file"
            :ref "dropzone"
            }))
  (did-mount [_]
             (let [node (om/get-node owner "dropzone")]
               (js/Dropzone. node #js {:url url
                                       :paramName "image"
                                       })))

interesting @noonian, i will look into that add-root!

You’d want to cause a render in the dropzone component, but if that refreshes things so you see the dropzone data from the callback, you’ll know thats the root issue

also, looks like add-root is only in om.next. i'm behind so will have to find another way to force the render

ah, I didn’t realize this was om now

that probably isn’t the problem then but not sure

Hello all! I'm wondering if I am missing something here on the parser server side ... my :action key function in the parser is mutating server side state and the :value is returning the :keys vector of what I want updated on the client, however the client is not updating said keys in the vector...? Just curious if I need to manually do it that is fine, but then what is the :keys vector for in the :value part of a mutation?

@tmorten: António Monteiro (one of Om committers) recently said that :keys are "just for documentation purpose"

i.e. :keys :value

Is tempids the way to go when creating new novelty that need to map back to actual keys on server side?

@tmorten: to creating novelty on client side?

@andrewboltachev: Both actually

@andrewboltachev: if my client sends the "tempid" along with the novelty that needs to be persisted and a new permanent ID is generated in the :action function (server side), how do I communicate that back to the :tempids map in the :value part?

@tmorten: You mean the problem is that :action doesn't have access to :tempids?

i.e. these are siblings in the map

@andrewboltachev: Indeed...I need to (d/resolve-tempid )in {:value {:tempids [...]} with a transaction that happens in the :action

@tmorten: Well, please check one of David Nolen's "Om Next" talks e.g. this https://www.youtube.com/watch?v=MDZpSIngwm4

I'm doing so to find an example

@andrewboltachev: will do. thanks for your help

@tmorten: https://www.youtube.com/watch?feature=player_detailpage&v=MDZpSIngwm4#t=1135 (at 18:55)

@andrewboltachev: @tmorten: I have a simple simulated tempid example somewhere, give me some seconds and I'll put it in a gist

@anmonteiro: Cool. Thank you. I think I may just need to put the datomic transaction in the let of the mutate possibly...then I would have access to the transaction which generates the ID...

@tmorten: Ah. This is a client-side only thing. With a simulated server

Not sure if still helpful

I just need to somehow communicate back to the :values map about my entity IDs from datomic transaction

right, can't help you there, still haven't tried it

anyways the gist is here: https://gist.github.com/anmonteiro/085d3d0636a3bc14f9f7

it's a variation of the Components, Identity & Normalization tutorial

@anmonteiro: Thanks and no worries. If I figure it out I'll put up a gist into group

and it's only meant to be looked at as an example, since it always generates the id 42 for newly created people

@anmonteiro: the function you provide to :action server side should return nil, correct?

This is probably the point I pull up the om source code

@tmorten: not sure if that's the case

swap! doesn't return nil

@anmonteiro: True...I can look it up, but do you know what the result of :action is supposed to be used for off hand?

i.e. {:action (fn [] @(d/transact conn....)}

does that get passed to client in some way -- cause it appears to not be and only :value key is returned to client

I think (IIRC) it will get sent to the client as the value of the mutation key (which is a symbol) so it would probably get merged into your app-state as the value of that symbol (and probably ignored by your app).

@tmorten: the result of the mutation is passed in under a :result key

so if your mutation is 'do/stuff!, the response from the server should be {'do/stuff! {:result {*whatever the result of the action-fn was*}}}

ok, and that will be merged back into app-state

no..

I think that depends on your merge-tree function

but I think the default one will merge it into your app-state, but thats just from memory and might not with the latest master

I'm just using the default one

@tmorten yes

My thoughts are to move away from entity ids and create a uuid via (squuid) and reference that on client side. I realize this is somewhat off-topic so I apologize. Has anyone done any Datomic/with Om.next that they could share experiences? Perhaps using the Entity ID as the client side ID is bad practice...

@tmorten: Datomic supports lookup refs you could probably make that work

I've been using uuid to create entities with datomic, called resource/eid. It works well with om.next. I had originally started creating external ids because migrating existing datomic ids from one database to another may not transfer correctly.

@dnolen: Does that work when introducing a new entity in a transaction? I see in the om-next-demo the "create/todo" wasn't implemented on client side, however, the rest of the app was using entity IDs it appears..

@tmorten: om-next-demo is just a demo

not a repo of best practices

@dnolen: no worries, I knew that was the case. Just wondering if anyone had experiences thus far with transacting new entities in datomic and trying to map those entities back to client side state

Anyone have any examples on how to prevent figwheel from resetting the state of the app. I tried declaring (defonce app-state (atom ...)), but that doesn't seem to be enough.

@nano you may also need to (defui ^:once Foo …)

otherwise new classes will be instantiated and React will re-mount everything

ah, hoping to continue developing straight on the TV now that I have the basic UI working. As I can do arbitrary cross site XhrIo requests, I'm hoping the ws:// figwheel channel will work fine as well.

also need defonce on the reconciler I think

defonce'd app-state and reconciler, and added ^:once to all defui's, when saving, all content disappears, even if the query remains the same. any suggestions?

@dnolen: not sure if any of this helps

Because of add-root!, the class will be instantiated anyways

even with defui ^:once

I've managed to get the app-state to be maintained on reload, but never component local state. Is this expected?

component local state = routing via queries for example?

or explicit set-state?

explicit local state

@nano: are you using routing with Html history?

if you are, that's a whole other problem

No, I should add history at some point. But right now I just replace the :child part of my top query that loads the child components.

As this isn't a browser application having the traditional history doesn't make much sense, but need to keep track of the navigation stack later on.

Right, no other ideas then; I'm reporting based on my experiments with adding Om Next reload behavior functionality to devcards

which is still on an open PR: https://github.com/bhauman/devcards/pull/91

but haven't tested with dynamically changing queries and such

Humm.. I think it might be the initial IQuery that's popping back, which defaults to my root.

So in the above snippet, session/route and session/params are still correct, but if I do (om/get-query (om/class->any reconciler App)) after the reload, the child points to :categories, instead of the target pointed out by :session/route (#object [cljs.core.Atom {:val {:session/route :category, :session/params { ....)