This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-01-17
Channels
- # admin-announcements (4)
- # aws (26)
- # beginners (88)
- # boot (132)
- # cljs-dev (4)
- # cljsrn (35)
- # clojars (11)
- # clojure (41)
- # clojure-art (33)
- # clojure-austin (1)
- # clojure-chicago (4)
- # clojure-dev (3)
- # clojure-russia (2)
- # clojured (3)
- # clojurescript (9)
- # community-development (19)
- # datomic (34)
- # devcards (2)
- # editors-rus (4)
- # hoplon (29)
- # leiningen (4)
- # music (2)
- # off-topic (21)
- # om (69)
- # other-lisps (1)
- # perun (6)
- # re-frame (1)
- # reagent (9)
- # spacemacs (3)
- # yada (13)
for example: I don’t see why this line is necessary if there is an ident on the board component: https://github.com/Jannis/om-next-kanban-demo/blob/master/src/kanban/parsing/boards.cljs#L49
@denik: In mutate
, you're operating against the normalized Om db by default. In this particular case I'm adding board
to the boards lookup table (`{:board {5 {:id 5 :name "" :lanes []}}`) and add a link to the board to {:boards [[:board 1] [:board 2] ...]]}
.
An alternative could be to construct a denormalized tree, use om.next/tree->db
to normalize it and then use some form of merge to merge the result into the app state, perhaps.
yeah, I wish this would be automatic. I have transactions that add large nested maps. DataScript took care of that for me but the Om story for that is not ready yet
@denik: Ha, mein natürlicher Schlafzyklus war schon immer um ein paar Stunden verschoben. 😉
Hmmm, I'd have to play with it but when adding large nested maps, perhaps you could denormalize the app state, merge the maps recursively and then swap a normalized version back into the app state? A little laborious perhaps...
Exactly, also adding the ref and the entry manually each time is not optimal and could lead to bugs
I wonder... since :action
can essentially do whatever it wants, you could use (om.next/merge! reconciler new-data)
. Might have to provide your own :merge-tree
to the reconciler at construction time but merge!
at least operates on the denormalized state and triggers normalization and post-merge updates automatically.
Might cause multiple rerenders though if you also provide read keys for anything affected by merge!
.
@anmonteiro: yeah.. that seems to be it, tried it now
horrible hack, but when adding meta, the render func is properly called when the :send callback gets the data.
I'm having a problem with advanced optimization. Every transact!
results in a JS error: "No queries exist for component path". In simple optimization mode there is no problem. Anyone run into this? Does this mean I need to define externs?
the error looks something like this:
designer.js:757 [ 2.450s] [om.next] [:flowport/by-id 5] transacted '[(gui/end-drag-element)], #uuid "be9fdedf-ec7e-430c-8906-b572efe9f4e3"
designer.js:815 Uncaught #error {:message "No queries exist for component path (#object[Yz \"function Yz(){React.Component.apply(this,arguments);this.state=null!=this.Jb?this.Jb():{};return this}\"] #object[Uz \"function Uz(){React.Component.apply(this,arguments);this.state=null!=this.Jb?this.Jb():{};return this}\"] #object[Qz \"function Qz(){React.Component.apply(this,arguments);this.state=null!=this.Jb?this.Jb():{};return this}\"])", :data {:type :om.next/no-queries}}Zy.f @ designer.js:815Zy.c @ designer.js:814Ez @ designer.js: @ designer.js:830qx @ designer.js:762Wy.b @ designer.js:798
@nano how many arguments are you passing to the callback in your send function?
@anmonteiro: One, https://github.com/dsvensson/svtplay-tizen/blob/master/src/svtplay/core.cljs#L69 dispatch-key would be :category if my child query is: [({:category [:item :short :title :url :image]} {:section "samhalleochfakta", :view "alphabetical"})] ...and its value is a list of items.
@nano so try passing (cb 1starg remote)
and see if it fixes your problem
You can pass the query that was sent as a 2nd arg to the callback and Om will use that
When I pass parameters to my updated route I construct a new query, that query doesn't contain metadata for what component the query is associated with, and thus render is not called, if I understand correctly. This seems to be the case, since when I scoop up the original metadata from the query and attach that to my parametrized query, render is being called correctly.
Just in the middle of BREAK-ALL-THE-THINGS since I can now continue with my app I'll try it out in a bit.
Ah, maybe I didn't understand your problem at first
but let me know if it works anyway ahah
Right, now I see that your problem might not be because of send
not expecting my suggestion to work then
How do I make a join that gets all the joined record, not just some of its parts? For example, in https://awkay.github.io/om-tutorial/#!/om_tutorial.D_Queries [{:chart [{:data [:cpu-usage]}]}] joins :data to [:statistics :performance], but then it selects [:cpu-usage]. How do I select all?
This might make it clearer: http://stackoverflow.com/questions/34841197/how-do-i-query-with-a-join-getting-all-the-data-in-om-next
still learning the basics of a full om next app. when it comes to remotes, is it typical to send an unparsed query to the server, and you parse it and run it there?
in the tutorial https://github.com/omcljs/om/wiki/Remote-Synchronization-Tutorial, it generates a cache-able URL "/api/02e397cc1447d688" to send a static query to, but how does the server know what query to run at that URL?
I guess I was expecting to use a GET and use the Cache-Control
header, but I guess by "http caching" you don't mean using actual HTTP headers, just a local cach?
I was under the impression that browsers do not really cache POST responses even if you give it the right headers. I'll have to test it, could be wrong
results are very confusing; I'll have to write some small test cases and see how various browsers behave
sure, I get the idea which is great, but as caching is an important part of the story it'd be good to note the requirements for serving it correctly
sure, even just 1 sentence about use POST to send the query to that URL would make it clearer to me.
Details can come later, definitely not a priority since it involves lots of decisions irrelevant for Om specifically
understood, just giving feedback as I go along. some of these things are relevant imho because you've made om next amenable to the current web stack
I am running into a very strange performance issue on Safari (on El Capitan) in both development and in advanced optimization mode. I have an app-state that has two credit card statements, each with lines. You are able to select between them which you want to show. The first statement has 10 lines, and the second has 500. If you select the small statement first and enter text into a textbox on one of the lines, the input is speedy. You can then select the large statement and edit lines on it, and it is quick as well. However, if you select the large statement first and edit a line, it is noticeably laggy. And if you then select the small statement it is laggy there too. Chrome and Firefox on OS X do not seem to have this problem. Here is a small runnable project that demonstrates the problem: https://github.com/caleb/om-input-perf-example/blob/master/src/perf/core.cljs
I am out of ideas on what to look for, I am really perplexed, since I think I’m doing everything right.
@caleb: You might try using this to narrow it down: https://developer.apple.com/library/mac/documentation/AppleApplications/Conceptual/Safari_Developer_Guide/Instruments/Instruments.html
@tony.kay Thanks, I did try using the timeline feature, but I’ll see if I’m missing something with those tools.
Hi all: I was recently running some experiments based on the remote synchronization and property based testing tutorials. I had a thought about query parameterization and I'd be curious what others think of this:
In the autocomplete example user input is used to directly change the AutoCompleter
query via query parameterization and om/set-query!
. However this causes a change in app-state while by-passing the parser's mutate implementation. By using query parameterization in this way, it seems we are missing a part of the mutation space needed to generate our user model in property based testing. It seems it would make it difficult to model the system as a state machine if we have a bunch of set-query! calls dispersed throughout the view code. How do you reach all app-states via the parser if you have parameterized queries? Does this mean you have to model the entire possible query space (via the parameters) as well? Not just the mutations?