Clojurians Log v2

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

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)}]

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

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

post-mutation is exactly how to handle this.

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

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

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").

^^^ @mitchelkuijpers

Yeah that is what I am currently doing, works fine

Just making sure I am not fighting untangled

sure

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

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

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

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

I'm not sure I understand

oh I see

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

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

so, it should "just work"

Ah cool, I thought that was the case

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

Ok

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

thanks for the heads-up

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

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

It will be soooo nice to have a beta

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

Yeah same for me

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

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

Yeah untangled kinda abstracted all the annoying stuff away

The unions stuff with the InitialAppState is pretty insane btw

works like a charm

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

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

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

Funny...I forgot I even did that diagram

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

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

we should pin it as well

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.

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

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

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