Fork me on GitHub
#om
<
2016-01-18
>
pupeno00:01:34

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

caleb00:01:44

@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.

dnolen00:01:11

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

dnolen00:01:24

Apple is aware of it.

dnolen00:01:08

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.

caleb01:01:47

@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

caleb01:01:05

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.

dnolen01:01:02

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

caleb01:01:11

Fair enough

dnolen01:01:17

Nothing but the reproducer.

caleb01:01:02

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

tmorten04:01:00

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?

jlongster04:01:26

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

jlongster04:01:18

@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)

jannis04:01:25

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).

jannis04:01:24

@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.

jlongster04:01:47

@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.

jannis04:01:35

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.

jlongster04:01:36

@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

jannis04:01:56

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

jlongster04:01:24

oh I see, thanks

jannis04:01:36

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.

jlongster04:01:55

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

jannis04:01:25

Good luck!

jimmy04:01:57

@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

jlongster04:01:52

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

jimmy05:01:28

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

jimmy05:01:40

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

jimmy09:01:50

@codonovan: awesome. thanks simple_smile

dnolen16:01:25

@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?

tony.kay16:01:50

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

tony.kay16:01:12

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

tony.kay16:01:18

but each have parameters

dnolen16:01:06

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

tony.kay16:01:10

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

dnolen16:01:32

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

tony.kay16:01:34

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

tony.kay16:01:06

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

tony.kay16:01:30

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

dnolen16:01:48

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

dnolen16:01:50

merging the PR

tony.kay16:01:25

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

dnolen16:01:53

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

tony.kay16:01:25

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

tony.kay16:01:07

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

tony.kay16:01:22

I think you closed that PR

dnolen16:01:59

was merged

tony.kay16:01:43

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

noonian16:01:15

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

noonian16:01:37

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

dnolen17:01:09

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

andrewboltachev17:01:45

Hi. Here, in 2nd sinppet https://github.com/omcljs/om/wiki/Components,-Identity-&amp;-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?

btking18:01:18

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

andrewboltachev18:01:17

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

andrewboltachev18:01:41

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

andrewboltachev18:01:03

(and what that ever means?)

btking18:01:52

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

btking18:01:59

if that makes sense simple_smile

andrewboltachev18:01:25

I wonder if you can share you code somewhere

andrewboltachev18:01:16

So we can take a look at it

andrewboltachev18:01:38

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

noonian18:01:05

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.

btking18:01:49

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"
                                       })))

btking18:01:29

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

noonian18:01:08

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

btking18:01:53

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

noonian18:01:47

ah, I didn’t realize this was om now

noonian18:01:59

that probably isn’t the problem then but not sure

tmorten19:01:33

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?

andrewboltachev19:01:18

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

andrewboltachev19:01:34

i.e. :keys :value

tmorten19:01:29

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

andrewboltachev19:01:16

@tmorten: to creating novelty on client side?

tmorten19:01:27

@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?

andrewboltachev19:01:45

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

andrewboltachev19:01:13

i.e. these are siblings in the map

tmorten19:01:34

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

andrewboltachev19:01:32

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

andrewboltachev19:01:45

I'm doing so to find an example

tmorten19:01:42

@andrewboltachev: will do. thanks for your help

anmonteiro19:01:16

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

tmorten19:01:36

@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...

anmonteiro19:01:23

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

anmonteiro19:01:32

Not sure if still helpful

tmorten19:01:35

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

anmonteiro19:01:57

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

anmonteiro19:01:33

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

tmorten19:01:59

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

anmonteiro19:01:20

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

tmorten19:01:28

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

tmorten19:01:28

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

anmonteiro19:01:28

@tmorten: not sure if that's the case

anmonteiro19:01:33

swap! doesn't return nil

tmorten19:01:18

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

tmorten19:01:01

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

tmorten19:01:38

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

noonian19:01:57

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).

anmonteiro19:01:04

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

anmonteiro19:01:08

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*}}}

tmorten19:01:47

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

noonian19:01:18

I think that depends on your merge-tree function

noonian19:01:37

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

tmorten19:01:41

I'm just using the default one

tmorten20:01:41

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...

dnolen20:01:34

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

taylor.sando20:01:37

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.

tmorten20:01:29

@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..

dnolen20:01:48

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

dnolen20:01:55

not a repo of best practices

tmorten20:01:11

@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

nano22:01:42

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.

dnolen22:01:13

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

dnolen22:01:38

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

nano22:01:44

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.

noonian22:01:35

also need defonce on the reconciler I think

nano22:01:32

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?

anmonteiro22:01:34

@dnolen: not sure if any of this helps

anmonteiro22:01:22

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

anmonteiro22:01:28

even with defui ^:once

anmonteiro22:01:15

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

nano22:01:57

component local state = routing via queries for example?

nano22:01:11

or explicit set-state?

anmonteiro22:01:19

explicit local state

anmonteiro22:01:37

@nano: are you using routing with Html history?

anmonteiro22:01:49

if you are, that's a whole other problem simple_smile

nano22:01:19

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.

nano22:01:14

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.

anmonteiro22:01:26

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

anmonteiro22:01:37

but haven't tested with dynamically changing queries and such

nano22:01:09

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

nano22:01:48

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 { ....)