Clojurians Log v2

hello, I found myself needing access to the reconciler in a post-mutation, can we make it available there?

@wilkerlucio you can get at the reconciler through the app atom

It's also available to any mutation via the env parameter, isn't it?

@grzm it's available on the regular mutations, but not on the post mutations, how do you get the reconciler from the app state?

the problem I believe is here: https://github.com/untangled-web/untangled-client/blob/master/src/untangled/client/impl/data_fetch.cljs#L311

in the post mutations it's only sending the state, not the full environment as on the regular mutations

https://github.com/untangled-web/untangled-template/blob/develop/resources/leiningen/new/untangled/dev/client/cljs/user.cljs#L21

(:reconciler @app)

That should do the trick

That line shows derefing the reconciler to get the app state, but you just need to get the reconciler, right?

@grzm thanks for the support, but that doens't work, at the post-mutations you don't have access to the app, only to the state, that's why I'm asking to add the reconciler there, so I can do reconciler operations at the post-mutation

you've got a global app atom somewhere, don't you?

I know reaching outside of a function isn't the first choice, but it gets what you need in this case

I agree that it would be nice to have more available in the env in the mutation

Perhaps a patch is in order, but there is a solution to your current issue as well 🙂

yeah, I'm bringing the discussion to see if there are any points against doing it, I would be happy to submit a patch for it

@wilkerlucio why do you need the reconciler as opposed to the state?

post mutations happen right after the data has been merged from the server, and before rerendering occurs

so having access to the reconciler is potentially dangerous

@ethangracer I'm changing a component query into a post-mutation, I wanna wait for the post-mutation to avoid some flickering, but without the reconciler I can't use functions like om/class->any to find my instances

I’m not understanding what you mean by changing a component query into a post-mutation

calling om/set-query on a post-mutation

interesting

so, the shortest possible answer would be that we have not been dynamically modifying queries, which is why we haven’t had a need for the reconciler

but also, I imagine calling set-query schedules a re-render

which would be bad inside of a post-mutation

humm, why triggering a re-render from a post-mutation is bad?

because it’s in the middle of a re-render cycle already

it would cause more screen flicker, if it worked

we had several issues with rerendering as we wrote data fetch, to be completely honest I’m not 100% on the technical internals

that would be a question for @tony.kay or someone else on here with a deeper understanding

humm, interesting, currently I have an implementation in place, but since I don't have the reconciler I'm using the reference for a component from the ::om/queries in the state, but that's a really bad way of fetching it, it improved my flickering situation, but I believe there might be better ways to archive it

I suspect that post-mutations probably aren’t the solution, at least not as we designed them. their only intended purpose is to give you access to the state atom post-fetch and pre-render

for example, if I want to invent some keyword :data that the server recognizes, and sends back some information that I don’t have a specific query for on the client

then I can use a post-mutation to pepper that information into the appropriate places in the app state

as for using om/set-query I can’t be much help because I haven’t used it 😕

umhum, just to get you more context, what happens in my case is that I use a dynamic query for routing

so, on a first step I have to get a new page query and trigger a server load

if I change the query at this stage, I'll have a new query and in place, but no data for it (still fetching)

so it loads the page without data, and that's a state that I don't want

so I was delaying the set-query to after the data was fetched

what about calling om/set-query and then immediately calling data fetch? you could use the loading marker at :ui/loading-data to render a loading UI while you wait for the fetch

instead of just a blank screen

or do you want it to load in the background?

that's a possibility, my current would be to don't replace the current screen until we have more data, it's not super important but it's a detail that I would like to be able to archive

yeah, background loading

that’s an interesting use case which I’m not sure we’ve thought about in that way

I just have one of those youtube-like thin loading bar at the top

I use the load markers to drive the loading bar, they are quite useful there

awesome, yeah that makes sense

fwiw, I think the way I’d try to approach something like that was by using routing with union queries and using the post-mutation to change the ident once the data fetch has completed. So that way, the UI doesn’t change until the data has returned from the server. not sure how well it’d work, but it’s another approach.

but I think your use case is a reasonable one if you’re not using union queries, in which case I’d be curious to hear thoughts from others on the untangled team once they’re online (probably another couple hours)

I feel like we’ve talked about background loading before but I can’t remember the context

umhum, I though about union queries at a point, but I'm building something that goes more into a website-like page, which means I have lot's of pages, the union query would be quite big and would keeping getting bigger, so dynamic queries sounded a better approach here

and I'm also curious about the other untangled core team thoughts are on this 🙂

I think the point of using a union query is that you’re able to change the active “branch” of the union query, allowing you to only query for a subset of the entire thing.

yes, union queries are great, specially when you have a predictable number of variations, I see the union queries more like for heterogeneous lists, when you are likely to use multiple of the branches at once, but for website routing I think it's a bit off, because you would always be sending the queries for all the pages (a number that can be quite large for a big site) only to actually fetch the data for one of then

not necessarily. you could just load the first page. then when you prepare to switch the ident, load the second page. etc. you certainly can load everything at once if you send the entire root query to server on app load, but you don’t have to

For example, we have a union query right below our root component to implement tabbed browsing. We just run data loads from each of the components in that union.

humm, you mean when you change a tab, you filter from the union query to ask for the server for that branch only?

@wilkerlucio yes exactly

PSA: the untangled team and @mitchelkuijpers are doing an untangled documentation write-a-thon this week. our plan is to make it easier to find the documentation that does exist, as well as fill out missing areas include our READMEs, reference guide, tutorial, and design conventions (mutation philosophy, data load philosophy, error handling, etc.). If anyone has thoughts on areas that could use documentation, we are open to suggestions.

Also, testimonials for the website would be greatly appreciated if anyone is willing? @jasonjckn @kenbier @currentoor @therabidbanana @wilkerlucio @gardnervickers @grzm

@ethangracer sure. I'll write one up.

@ethangracer of course! Should I just direct message it to you?

@ethangracer sure! adstage could add one, its been great for us

@currentoor @grzm thank you! yeah a DM to me works. If we could post company logos that would be helpful too — we want people to know that real companies are using this tool for code in production. No worries if we can’t, but if we can that’d be great!

ok: what I want to do: test mutations that reference env ref, so I'll need to be able to run transact with the appropriate component, correct? Which means I'll need to instantiate the app, right? And mount it?

Why don't you test the mutation by running it directly?

why make it an integration test?

pass it some made-up state in the env

That's why I'm asking, cause I'm currently thinking this through.

Yeah, avoid integration tests...they are slow/heavy/fragile

prove that your mutation works as a pure function

That makes sense.

make a minimal mock db in state, put the ref and state in env, then show it results in correct post state

Our protocol testing support can help with that, but it is undocumented

(correcting that this week, I hope)

((:action (m/mutate {:state (atom {:test :state}} :ref [:expected :ident]} ’some/mutation {:params :list})))

Thanks for the sounding board, guys

yep

@tony.kay hey, if you have some time, can you please give me your thoughts on the idea of using the reconciler on post-mutations? (regarding the discussion early here) would your consider making the reconciler available there?

no I would not suggest doing that

use-case?

https://clojurians.slack.com/archives/untangled/p1475503257001609

@wilkerlucio what is your use-case?

I'm doing routing with dynamic queries, I fire the query for that page to load, and in the post-mutation I change the parent query (after the data has come in), I need the reconciler so I can access the indexer (making easier to find the element to set-query on)

did anyone save tony’s "blog post” in the channel about the reasoning behind server mutations never returning data, and following up with server loads instead? @therabidbanana @mitchelkuijpers I seem to remember you both chatting about it

@tony.kay ^^, or for the long version: https://clojurians.slack.com/archives/untangled/p1475503257001609

@ethangracer by "blog post" do you mean the exact text of the message, or just the subject I found interesting and worth writing out in the message?

the exact text 😬

I realize it’s a long-shot ask

slack just erased it

@ethangracer https://clojurians-log.clojureverse.org/untangled/

have fun

Oh, looks like it's just beyond the threshold of time for Slack

@anmonteiro Sweet...didn't know about that nugget

@anmonteiro 😆

thank you

there go them darn programmers making things better (also known as working around product paywalls)

https://clojurians-log.clojureverse.org/untangled/2016-09-27.html <- it's on this day specifically

thanks everyone!