Fork me on GitHub
#untangled
<
2016-10-03
>
wilkerlucio12:10:51

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

grzm13:10:53

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

grzm13:10:57

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

wilkerlucio13:10:26

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

wilkerlucio13:10:53

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

grzm13:10:25

(:reconciler @app)

grzm13:10:34

That should do the trick

grzm13:10:36

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

wilkerlucio13:10:03

@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

grzm13:10:21

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

grzm13:10:54

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

grzm13:10:11

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

grzm13:10:39

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

wilkerlucio13:10:07

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

ethangracer14:10:57

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

ethangracer14:10:18

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

ethangracer14:10:29

so having access to the reconciler is potentially dangerous

wilkerlucio14:10:59

@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

ethangracer14:10:36

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

wilkerlucio14:10:47

calling om/set-query on a post-mutation

ethangracer14:10:06

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

ethangracer14:10:20

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

ethangracer14:10:29

which would be bad inside of a post-mutation

wilkerlucio14:10:00

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

ethangracer14:10:10

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

ethangracer14:10:28

it would cause more screen flicker, if it worked

ethangracer14:10:29

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

ethangracer14:10:12

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

wilkerlucio14:10:17

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

ethangracer14:10:34

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

ethangracer14:10:45

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

ethangracer14:10:01

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

ethangracer14:10:49

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

wilkerlucio14:10:26

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

wilkerlucio14:10:49

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

wilkerlucio14:10:09

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

wilkerlucio14:10:27

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

wilkerlucio14:10:47

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

ethangracer14:10:39

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

ethangracer14:10:49

instead of just a blank screen

ethangracer14:10:28

or do you want it to load in the background?

wilkerlucio14:10:31

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

wilkerlucio14:10:39

yeah, background loading

ethangracer14:10:11

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

wilkerlucio14:10:12

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

wilkerlucio14:10:34

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

ethangracer14:10:52

awesome, yeah that makes sense

ethangracer14:10:12

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.

ethangracer14:10:15

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)

ethangracer14:10:35

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

wilkerlucio14:10:07

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

wilkerlucio14:10:50

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

gardnervickers14:10:30

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.

wilkerlucio14:10:39

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

ethangracer15:10:41

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

gardnervickers15:10:43

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.

wilkerlucio15:10:06

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

ethangracer18:10:05

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.

ethangracer19:10:03

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

grzm19:10:12

@ethangracer sure. I'll write one up.

currentoor19:10:01

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

kenbier20:10:55

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

ethangracer20:10:55

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

grzm21:10:45

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?

tony.kay21:10:23

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

tony.kay21:10:31

why make it an integration test?

tony.kay21:10:45

pass it some made-up state in the env

grzm21:10:00

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

tony.kay21:10:15

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

tony.kay21:10:23

prove that your mutation works as a pure function

grzm21:10:44

That makes sense.

tony.kay21:10:44

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

tony.kay21:10:58

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

tony.kay21:10:03

(correcting that this week, I hope)

ethangracer21:10:20

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

grzm21:10:26

Thanks for the sounding board, guys

wilkerlucio21:10:02

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

tony.kay21:10:40

no I would not suggest doing that

tony.kay21:10:26

@wilkerlucio what is your use-case?

wilkerlucio21:10:05

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)

ethangracer21:10:06

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

therabidbanana21:10:03

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

ethangracer21:10:26

the exact text 😬

ethangracer21:10:31

I realize it’s a long-shot ask

ethangracer21:10:53

slack just erased it

therabidbanana21:10:28

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

tony.kay21:10:09

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

tony.kay21:10:37

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

ethangracer21:10:45

thanks everyone!