are there any visualizers for the app state — something that draws out the tree or graph structure visually (and ideally updates live as I'm working)?
@tony.kay around 14 minutes into that video you introduce person-list-by-id
(`plbi`) in the app state. That makes sense, but where would you define the initial values for plbi
for InitialAppState
? Would that be specified on the PersonList
component?
I've gotten this far, and things are starting to make sense:
(defui Filter
static uc/InitialAppState
(initial-state [this params] [{:db/id 1 :name "Initial Filter 1"} {:db/id 2 :name "Initial Filter 2"}])
static om/IQuery
(query [this] [:db/id :name])
static om/Ident
(ident [this {:keys [db/id]}] [:filters/by-id id])
Object
(render [this]
(dom/div nil ((om/props this) :name))))
(def ui-filter (om/factory Filter {:keyfn :db/id}))
(defui FiltersList
Object
(render [this]
(dom/div nil (map ui-filter (om/props this)))))
(def ui-filters-list (om/factory FiltersList))
(defui Root
static uc/InitialAppState
(initial-state [this params] {:ui/react-key "ROOT"
:filters-list (uc/get-initial-state Filter nil)})
static om/IQuery
(query [this] [:ui/react-key
{:filters-list (om/get-query Filter)}])
Object
(render [this]
(let [{:keys [ui/react-key filters-list]} (om/props this)]
(dom/div #js {:key react-key}
[(str (om/get-query Root))
(dom/br #js {:key "BR"} nil)
(ui-filters-list filters-list)]))))
Two things tripped me up:
1. I didn't realize that the :filters/by-id
table in the app state is automatically generated, and that I don't need to do anything to make it appear.
2. It feels strange that I'm defining the initial list of filters on the Filter
component (which ostensibly renders a single Filter), rather than the FiltersList
component or somewhere else.@fz, yes as the ident of PersonList
then have initial state that gives whatever values you need in the node
if person list is going to have an ID, it will need to be in the initial app state map, so that the ident function cna find it to normalize
Not sure why you have FiltersList in your example, since it is just acting as a div
Make sure you've gone through the basics of the devguide and the getting started videos. That most recent video assumes you already know how to assemble the UI and queries and get something on the screen. I gloss over a lot in that more recent video since it is about reasoning through data lifecycles.
Example updated — FiltersList
does the map
and renders Filter
s
What does "it" refer to — the ID of the person list, or the :person-list
edge itself?
Thanks Tony. I've tried, but — this is probably indicative of how my brain works more than anything else — I felt like the first half of this recent video pulled things together in a way that the other resources didn't.
IMHO that video needs to be featured on the untangled website. Since I've watched it, everything just fell in place, and there's a lot less uncertainty on how to do things. 👌
I'd be interested in hearing what order you recommend people work through the material. I certainly want to link the video in, but I don't want people watching it in an order that doesn't make sense.
It could be stupid question, but why additional layer as untangled over om.next? I am trying to find any text about it but i can’t. I am trying to feel the point.
@tony.kay Well, I can only speak to how I worked through the material, and speculate on how I could have done it better. But here goes:
I first watched your talk in Portland to get a general overview. Then I watched the one from Clojure West. I enjoyed both of them, but as far as learning one would probably suffice. Perhaps the one from Clojure West is more concise.
After that, I think the reference guide is good to get a more precise overview. Before that, perhaps the video series where you build an example application.
Then I would skim the dev guide
After that, watch the video you posted
After that read the dev guide more attentively
But this is a very subjective view, obviously 🙂
It's probably good to try getting your hands dirty in between, and actually try to write something, so that the explanation are then more meaningful, and have more context
@kwladyka The general model of Om Next is great, but it is really a set of building blocks that leaves a lot for you to decide and implement. Untangled provides a clear set of those decisions with implementations of those choices. It really isn't so much a "layer on top" as it is a specific implementation of the low-level requirements anyone has to build to use Om Next.
Oh...and documentation 😉
@tony.kay Thanks. I think i get the point.
@tony.kay it’d be nice/useful if uc/history
could take a reconciler, or if the untangled-client app was available in the parser environment.