@tony.kay: will do, thanks!
hello people, about the case when you want a partial query that isn't on any component and also need an ident with it. the docs for untangled recommend that we create a class just for the query. I'm have being toying with a different approach, in my case at least, most of my idents follow a common pattern, that is: [(:db/table props) (:db/id props)]
so I created a helper like this:
then I can just write: (untangled/load {:query [{:app/me ~(with-ident [:db/table :db/id :user/score])}]})
what you think about this approach?
@wilkerlucio Well, the plus is you don't generate unneeded code. I really think this is a problem in core Om as well. So, I would not want to integrate a solution in Untangled...but I would advocate for something like it in Om. The thing is, it is possible they could hcange the implementation (e.g. the keyword :component could get namespaced) in a way that breaks this function....so they should evolve together.
I got the idea of using defui to make queries from David Nolen....it is an accepted and recommended technique for Om
yeah, I guess making it explicit also gives more information later if you wanna track it
and get-query
might eventually add other metadata....just too fragile this way without being part of Om
then again, easy to fix as Om evolves....well, I think
could be that it starts adding metadata related to something else on the component, in which case you're better off with defui overall. I'd be happy with an alias for defui...like defquery
well, maybe not an alias, but something that assumes you might want a query + ident.
umhum, gotcha, the stability seems reason enough to use the query component, I'll refactor to use that on my code, thanks @tony.kay for your input
@tony.kay @wilkerlucio IMO you should just use defui
for the reasons Tony mentioned and also because of future enhancements like better error messages and stuff
also, I donβt think Om is going to add any sugary stuff, so defquery
would probably need to be in user land
Yes, I understand that. David has refused all manner of sugar π
no hyper-glycemia happening in that library
:simple_smile:
thanks for the docs!
Welcome, @jasonjckn. Be glad to hear feedback or accept PRs. Really trying to make this stuff easy to learn.
I recall some roll back mechanism for optimistic updates you were talking about ? docs? examples?
for optimistic updates? No
server errors
optimistic is local and deterministic within your mutation
maybe I should read those docs you wrote π
there's a doc typo I think s/defmutation/defmethod
http://untangled-web.github.io/untangled/tutorial.html#!/untangled_tutorial.H_Server_Interactions
what was the rollback thing you guys were talking about? this was server side? docs?
was this specific to datomic?
should totally be defmethod
fixed