@jasonjckn: I’m working on a project that is half high-level overview of the component technologies, half tutorials for building basic UI that will tie back code samples to those high level concepts. If that’s the thing that you feel may help your team, feel free to ping me with ideas and thoughts https://github.com/egracer/untangled-intro

@ethangracer: Thank you for this, I’ll give it a whirl 🙂...

great, still very much in development — whole sections not finished yet (currently no coding sections). my goal with the sections finished so far is to simplify the high level overview to a point that it makes sense but doesn’t sacrifice technical accuracy or depth. any feedback is definitely appreciated

@enth

@ethangracer: wonderful stuff, yah this will help the team, looking forward to seeing you fill it out

are 'links' suppose to work at any depth in the root query? from the docs it sounds like they always bring you back to the root of the database

so I wrote as a root query

{:foobar [{[:todo-list/by-id '_] [:title]}]}

{:foobar [{:foobar [{[:todo-list/by-id '_] [:title]}]}]}

so, usually you want to use links to access top-level data, because requesting a table with idents will return a lot of data

erm...right form, but you don't access tables that way...use an ident for that

[{[:todo-list/by-id 42] [:title]}]

that should work at all depths?

i'll test that..

my db is {:foobar {:foobar {}} {:todo-list/by-id {...}}}

Yes, any depth. links should go to a top-level key...e.g. app state might say {:item [:list/by-id 3]} and then a query joined on [:item '_] would work

@tony.kay: can you add an ident at any level of the query to get at the data at that ident?

I thought that links were a special query form

Idents point to items in tables. Links point to top-level keys which in turn are linked via idents

links are specifically the term for idents that have '_ for their ID portion

which means "top level singleton"

if it isn't a singleton, then you need an ident

both, by definition, start at the root of the app state

since idents are hitting tables

i just tried that I have a root query of

{:foobar [{:foobar [{[:todo-list/by-id 1] [:todo/title]}]}]} 

{:foobar {:foobar {}} :todo-list/by-id {...}}

that is not a normal query, it is a union

do you mean to imply it is in a vector? (e.g. just forgot to copy that bit)

Also, I assume your nested table has a key for 1, and a value there that has a :todo/title

yes

i left out the outer [ ]

yes

it does

i'll query at the REPL the exact data/query i'm working with and paste here to clarify

query

[:ui/support-visible :ui/react-key :ui/locale {:foobar [[:items _] [*]]} {:todos [:db/id {:list/items [:db/id :item/label :item/complete :ui/editing]} :list/title :list/filter]}]

:initial-state {:list            (or (get-url-param "list") "main")
                                     :todo/by-id      {1 {:db/id 1 :todo/title "got milk?"}
                                                       2 {:db/id 2 :todo/title "bar"}}

                                     :todo-list/by-id {1 [[:todo/by-id 1]
                                                          [:todo/by-id 2]]}

                                     :items           [[:todo/by-id 1]
                                                       [:todo/by-id 2]]

                                     ;;:main            {:dev {:todos [:todo-list/by-id 1]}}
                                     :foobar          {:foobar {:foobar {:foobar nil}}}

                                     :todos           {:list/title  ""
                                                       :list/items  []
                                                       :list/filter :none}}

so that one is 1 layer deep and works just fine,

if I change the query to 2 layers deep it won't work

that is hand normalized...has to be in an atom to do that.

you're probably getting errors in the console on start

no errors just

[196.704s] [om.next] RERENDER: NOTE: If your UI doesn't change, make sure you query for :ui/react-key on your Root and embed that as :key in your top-level DOM element

okay, so don't hand normalize initial state, got it

and that should fix the issue?

So, remember that the UI query is used for normalization..do you have queries on your UI? If so, are you composing them together? Do you have idents on your UI?

If you want to just play with raw data and raw queries, use db->tree directly

If you plug an app database into untangled without an atom, it tries to use the UI query to normalize it. If you use a raw (non-composed query) then metadata will be missing from the query for normalization.

yah, these queries are on the UI

but i did the nesting of :foobar :foobar manually, there's no idents behind them

well, and the query looks incorrect, too:

{:foobar [[:items _] [*]]}

that works fine 1 layer deep though

i don't think the issue is around [[:items _] [*]]

it isn't a join

the inner part, that is

I mean, you can probably use a link without a join...but you'll get a raw dump of the thing at the location in state

you won't be selecting keys from it

ok, sorry, that was a typo, my other tests didn't have that typo

trying queries again

[:ui/support-visible :ui/react-key :ui/locale {:foobar [{:foobar [{[:items _] [*]}]}]} {:todos [:db/id {:list/items [:db/id :item/label :item/complete :ui/editing]} :list/title :list/filter]}]

the join is in there

i can try baking :foobar into the UI next

no

;(defui ^:once NewComp
  static om/Ident
  (ident [this props]
    [:newcomp 1])

  static om/IQuery
  (query [this]
    [{:foobar [{[:items '_] '[*]}]}])

  Object
  (render [this]
    (dom/div nil
             (prn-str (om/props this)))))
(def new-comp (om/factory NewComp))

(defui ^:once Root
  static om/IQuery
  (query [this] `[:ui/support-visible
                  :ui/react-key
                  :ui/locale
                  #_ {:main [{:dev [{:todos ~'[*]}]}]}
                  {:foobar ~(om/get-query NewComp)}

                  #_ {:ui/main [{:dev [{:todos [:db/id :todo/title]}]}]}
                  {:todos ~(om/get-query TodoList)}])

this code works great though

(defui ^:once NewComp
  static om/Ident
  (ident [this props]
    [:newcomp 1])

  static om/IQuery
  (query [this]
    [{[:items '_] '[*]}])

  Object
  (render [this]
    (dom/div nil
             (prn-str (om/props this)))))
(def new-comp (om/factory NewComp))

(defui ^:once Root
  static om/IQuery
  (query [this] `[:ui/support-visible
                  :ui/react-key
                  :ui/locale
                  #_ {:main [{:dev [{:todos ~'[*]}]}]}
                  {:foobar ~(om/get-query NewComp)}

                  #_ {:ui/main [{:dev [{:todos [:db/id :todo/title]}]}]}
                  {:todos ~(om/get-query TodoList)}])

so first, try putting your state in an atom, so it knows it is already normalized

i tried that it just broke the whole app

i'll need to dig deeper with that one

few minutes... there

okay, so doing that makes neither of the 2 codes above work

if i pass an atom to initial-state

what is the error?

fixed it, parinfer messed up parens

i turned it off

back on track

and if you give a component an Ident, then it has to exist in the app state at that db table location

or re-render and all manner of things go sideways

okay, i'll fill in that ident

Basically, your ident functions need to follow the structure of your db

If you compose in a component that gives an ident, then the data for it better exist in a table at that ident location

oh cool, they both work now! both 1 and 2 layers of foobars

right

great

yah it was the atom on initial state that did the trick

Using an atom turns off auto-normalization

That needs better docs, perhaps.

just turns it off for initial state though

nods

I suspect there is a bug right now as well. Afaict you can’t force auto-normalization at all when passing in an atom with the latest alphas; you used to be able to pass in :normalize true when constructing the reconciler but that seems to have stopped working.

Noticed that last night.

Hey Jed, Hm. I'll have to look at that

That would be a breaking change

Howdy 🙂

@tony.kay: I think it may have been this commit: https://github.com/omcljs/om/commit/6243eb499b865894ba680cb8e6c56db9d404d8a8

norm? will be true when passing in an atom and in add root it only normalizes if the :normalize flag is set and norm? is falsey.

Yea, I did that. Makes it possible to do all of the variants you might want

I don’t understand that. How can you pass in an atom and still get it to normalize since norm? will always be true and thus it will never normalize during add-root?

So, if you pass in an atom, Om knows you hand normalized it.

I worked around this by just passing in a map and getting a reference to the atom after the reconciler was created using om/app-state.

If you pass in a map, it knows you did not

you can't...but you don't have to

right, but you used to be able to pass in :normalize true in the reconciler to tell it that your atom is not normalized (and enable normalization for merged etc.) but that no longer works after this change.

you either want normalization ON or OFF in the entire app. Untangled ALWAYS turns it on

Right, you used to, but that made it impossible to do the thing you really needed

hehe, which is?

Pass in hand-normalized data, but also ENABLE normalization on merge

I’m just talking in the context of Om next and not untangled btw.

that is the more common case...it is trivial to NOT pass an atom to say you didn't normalize it

so, now it is possible to do every case, just the API changed slightly...don't pass an atom if you mean to indicate non-norm data

It seems like the :normalize key has zero effect now.

every case except pass in a pre-existing atom and turn on normalization

:normalize does exactly one thing, ever: turns on or off auto-normalization (for merging novelty on server returns, and initial state iff it is not an atom)

This is an Om concern, since normalization is always on in Untangled

The choice of an atom simply lets you choose to hand-norm your initial data

I agree, my question is really is it intended that the public api should change in this way.

Yep

Discussed it with David and Antonio...there was no way to get the case some people needed with the old behavior

which was pass in a map and keep normalization off?

Cases: 1. You want normalization everywhere: pass a map as initial state, and normalize true 2. You want normalization everywhere, except initialization: pass an atom and normalize true 3 and 4. You don't want normalization: pass in whatever the hell you want for initial state and set normalize false

Ah, so it was case 2 that was unsupported

so now all 4 possible combos are covered

yep

and it is a case I wanted for Untangled

It looks to me that you could handle all cases and allow passing in an atom with normalization turned on by adding another param to reconciler like skip-initial-normalize? and instead of :normalized norm? when creating the reconciler state you’d have :normalized skip-initial-normalize?. That way it wouldn’t be a breaking change either.