Fork me on GitHub

can om take care of normalizing new entries during a mutate?


for example: I don’t see why this line is necessary if there is an ident on the board component:


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


yep I understand


could om do an ident lookup and add the ref automatically?


An alternative could be to construct a denormalized tree, use>db to normalize it and then use some form of merge to merge the result into the app state, perhaps.


also: @jannis warum schläfst du nicht?


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


- so I pulled it out


das kenne ich zu gut mein Lieber


8.46pm... a German expat? 😉


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


okay will dig into that


@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] [] [: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}}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, 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


What problem?


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.


I'll see if your suggestion works though.


Just in the middle of BREAK-ALL-THE-THINGS since I can now continue with my app simple_smile I'll try it out in a bit.


Ah, maybe I didn't understand your problem at first simple_smile


but let me know if it works anyway ahah


I'm not famous for being very good at explaining simple_smile


yep, will do.


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!/om_tutorial.D_Queries [{:chart [{:data [:cpu-usage]}]}] joins :data to [:statistics :performance], but then it selects [:cpu-usage]. How do I select all?


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


(or: how does the server install handlers for that URL?)


ah ok, so no GETs ever?


You could use get, but I don't see the point it's just one endpoint


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?


Cache-Control can work with POST far as I know


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


I recall using this trick at the Times


We might have used Etags - but the point is you can get a stable URL


results are very confusing; I'll have to write some small test cases and see how various browsers behave


oh yeah, etags is another thing


How you serve the first request is up to you


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


right not interested that


People can sort it out


Generic web stuff


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


Same reason we don't talk much about DB decisions at great length


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


Right priorities. Stuff you can find on Stack Overflow vs things we must answer


Former is very low priority


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:


I am out of ideas on what to look for, I am really perplexed, since I think I’m doing everything right.


should be able to see what is going slow


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