if anybody is interested in a relatively simple PR, that would be a good one. the keys that we use in the default reconciler config should definitely not be overwritten

@ethangracer: thanks for the reply, actually I found out that my problem wasn't related to that, I fixed with something else

although, I agree with you about the reconciler options, having then being configurable is a must

@tony.kay: I notice nice Untangled T-shirt 😄

@wilkerlucio: There is no problem, in principle, with letting you send extra args, but realize we've provided stuff for: - Parser - Merging - Networking

and none of that should be touched. If you have specific configuration options you want access to, would be willing to make them available if they make sense. It is important to understand that a lot of the stuff you can configure in Om is configured to "just work" correctly...e.g. tempid remapping is fixed...deep merge and attribute stomping....lots of stuff.

We're writing big stuff, and have not needed overrides

@nxqd: Thanks! I'll be wearing some additional colors here and clj west

@wilkerlucio: You don't need to set id-key. Tempids "just work". We've fixed them. Just return a {:tempids {}} remap from you server-side action...which is a touch-up from Om as well...they'll automatically get sent back and merged properly

The whole point of Untangled is that you should not have to configure things like the id-key, merge behavior, etc.

@tony.kay: thanks, one case that I'm still missing configuration options is about the logger, I would like to disable it

@wilkerlucio: it is currently broken on the public repo, but the untangled.client.logging namespace has a set-level function that you can use to turn the logging off. Right now it it'll change the logging level appropriately for every level except for off

Call it in your dev user namespace before mounting the app

@ethangracer: cool, but what about the Om itself logging (that happens on transactions), is that going to be disabled as well?

Yes, we just hijack om's logger and use it ourselves 😄

So if you turn logging off, om stops logging too

cool

thanks for the clarification

I’m watching Tony Kay’s presentation but don’t understand how you can eliminate query params. If I want to load the fifth page of comments, how is that accomplished without a query param?

@joshg let’s say you have a list of 25 items, and you want to show them 5 at a time

your database will have idents that look like [:item/by-id 1] [:item/by-id 2] …

so you set up your UI to load initially and only use the first 5 idents

then when the user clicks the link to switch to page 5, you just swap out the idents in the app state that belong on page 5

i.e. 20 - 25

What if I don’t know those idents yet?

then you load them from the server

So it takes two trips to load the next page?

if they don’t exist at all, i guess don’t show a link to page 5?

or you could load the first page as one load, and immediately load all the other pages. just don’t show them immediately

e.g. (app/load page-1) — render page 1 — (app/load remaining-pages)

also, changing pages is just a UI concern, so that doesn’t require a trip to the server

so even if you load each page one at a time, it’s only one trip per page

What if the user clicks on page 20? Would I have pre-loaded all idents for each page?

totally depends on your implementation

you get to decide how you want to do that

Assuming that the cost to preload all results is too high, the way to load page 20 would be to request the idents from the server and then swap them, which will load those idents?

Or would it make sense to actually put pages in the app database?

@joshg you could load a map like this: {:list/page 1 :list/total-pages 3 :list/items [...]}

since Untangled use explicitly commands to load the data, you can send the current page to load via a param, the first load would always use page 1, and the others would be sent

and then have a page mutation to increment the page?

with the info on that map you can figure if there is a next page

then you could use something like: (df/load-data reconciler [{:some-list [:list/page :list/total-pages {:list/items (om/get-query ItemsComp)} ]}] :params {:list/page 2})

that makes sense?

Yes, I think so. That seems like cleaner solution that would support more traditional paging queries.

Thanks @ethangracer and @wilkerlucio for your help

welcome!

no problem