Fork me on GitHub
#untangled
<
2016-09-27
>
mitchelkuijpers06:09:56

@tony.kay Thank you so much for the explanation, I think I am going that way. Definately deserves a blogpost

mitchelkuijpers19:09:44

Is it correct that the :marker true options blows away any state you have in that part of the application? For example when I do a query on and run load-data:

:confluence.autocomplete/spaces [:ui/fetch-state
                                 :total
                                 {:results (om/get-query Space)}]
It will blow away :results and :total when loading and resets them when loaded. I fixed it by making a post-mutation which moves the options somewhere else and I render from there (so that I don’t lose the current resultset when it is loading a new one). Is this the way you are suppose to fix this or did I stumble upon a bug?

tony.kay20:09:05

So, in general when you are loading data you should understand that the data you're targeting is to be overwritten.

tony.kay20:09:17

when you use markers, then yes, it overwrites teh data with the marker

tony.kay20:09:14

post-mutation is exactly how to handle this.

tony.kay20:09:17

The idea of marker is so you can show a "loading" or spinner in place of the real data. There is a global loading marker at [:ui/loading-data '_] (I think that is the name) that is for showing a "network xfer in progress" kind of thing in a non-localized position

tony.kay20:09:05

So, if you want the results to stay in place, use :marker false

tony.kay20:09:59

If you want some combo (e.g. a localized loading marker, but the results to stay in place) then have your mutation create your own kind of localized marker that you clear in post-mutation. All sorts of ways to solve it. The load markers (global and local) are a convenience for the common two cases (network xfer in progress, and "please wait while I fetch that, but I have nothing yet").

mitchelkuijpers20:09:30

Yeah that is what I am currently doing, works fine

mitchelkuijpers20:09:42

Just making sure I am not fighting untangled

tony.kay20:09:37

The general pattern is: db -> UI render -> event -> mutations/fetches (modify db, possible send remotes) -> UI render -> network completion (db change) -> optional post-mutations (db change) -> UI render repeat

tony.kay20:09:30

Since the UI render is supposed to be a ref transparent rendering (for the most part) all you're really managing is the shape of the data and queries

mitchelkuijpers20:09:23

Now that I got you here do I ever need to add refreshes or reads in mutations for :ui/fetch-state or ui/data-loading

mitchelkuijpers20:09:45

Copied you're general pattern that’l come in handy

tony.kay20:09:55

I'm not sure I understand

tony.kay20:09:39

Om will put the components that trigger network requests in the queue of things to re-render

tony.kay20:09:00

and on post-mutation we actually force a global render (if I remember right...we change the react-key)

tony.kay20:09:11

so, it should "just work"

mitchelkuijpers20:09:41

Ah cool, I thought that was the case

tony.kay20:09:53

yeah, if they don't update I'd consider it a bug

mitchelkuijpers20:09:03

Btw if anyone runs into weird subvec errors with om 1.0.0-alpha45 you should upgrade to 1.0.0-alpha46 I got bitten by this bug a lot: https://github.com/omcljs/om/pull/767

tony.kay20:09:33

thanks for the heads-up

mitchelkuijpers20:09:00

This was the reason I was asking about add-root! and remove-root! because I got this error when I removed a root

mitchelkuijpers20:09:41

They did a lot of fixes in the new version I guess they are working towards the first beta

tony.kay20:09:13

It will be soooo nice to have a beta

tony.kay20:09:41

not been that big of a deal, but the "is this a bug or the way it should work" has been a bit of a pain

mitchelkuijpers20:09:51

Yeah same for me

mitchelkuijpers20:09:06

And they bugs are pretty damn hard to figure out (if you even figure them out)

tony.kay20:09:40

fortunately the core stuff has been relatively stable. We've only lost a few total days of productivity on that kind of thing in months

mitchelkuijpers20:09:59

Yeah untangled kinda abstracted all the annoying stuff away

mitchelkuijpers20:09:33

The unions stuff with the InitialAppState is pretty insane btw

mitchelkuijpers20:09:36

works like a charm

mitchelkuijpers20:09:14

My first stuff with unions and om.next took me 2 days lol

mitchelkuijpers20:09:34

Well I’ll be off, thnx for the help @tony.kay (again)

mitchelkuijpers20:09:53

http://untangled-web.github.io/untangled/reference/reference.html#_overall_network_plumbing found an image of what you were talking about I somehow missed this earlier

tony.kay21:09:56

Funny...I forgot I even did that diagram

tony.kay21:09:35

and glad to hear you appreciate the InitialAppState stuff. I was pretty darn happy when that stuff (esp. the Union simplification) fell out

adambrosio21:09:22

oh wow i forgot about that reference page let me bookmark that lol

adambrosio21:09:21

we should pin it as well

tony.kay21:09:00

Of general interest: Members of the Untangled Team are doing a week-long documentation sprint next week. We have not identified all of the targets, but it'll be 4-5 people for 40 man hours. We should see some significant improvements.

tony.kay21:09:14

Anyone in the OSS community that wants to join in, let me know!

adambrosio21:09:43

http://untangled-web.github.io/untangled/reference/reference.html This reference guide is meant to be an indexed document for quickly finding information about the Untangled Web Framework. If you’re trying to learn Untangled, then you should do the https://github.com/untangled-web/untangled-tutorial

tony.kay21:09:45

So far it'll be me, @mahinshaw, @adambros, @ethangracer, and our tech editor.