untangled 2017-02-24

@tony.kay: finally got to section H: http://untangled-web.github.io/untangled/guide.html#!/untangled_devguide.H_Server_Interactions it may be that I'm slow, but it took me 2 days to get through the basics of untangled to get to the interesting (networking) part 😕

https://github.com/untangled-web/untangled-ui <-- is the only way to view the components to clone the repo and run it locally ? 🙂

@qqq It takes a while but it is worth it

Is there a "minimal" untangled client/server example? The todo-mvc is > 600 LOC, I'm looking for something at ~ 50LOC where it's minimal client/server, and nothing else.

@qqq have you tried the getting started videos? I know you are not interested in the Cursive parts, but there is a lot of info in there, and many ppl have found them easier to get going on. I'd be interested in your experience

@mitchelkuijpers @wilkerlucio @currentoor @jasonjckn @therabidbanana I've proposed a "Why Om Next/Untangled" Unsession at clj west. I'd be really interested in input you might have on your experience with competing popular tools and why you are here. I don't have a lot of explicit experience with things like Re-frame et al, so it would be helpful to have some external input. In particular, if any of you would be willing to have a skype/hangout/voice chat of some sort in the coming weeks it would be really helpful. Trying to do some community building.

I am in @tony.kay we are still migrating away from re-frame

@tony.kay the major Untangled selling point to me is: you gonna have to write this anyway, so better have this as a library we can all collaborate on instead of trying to rewrite every time

I was really impressed on the beginning, when I was trying to write my own, and then you came with Untangled solving the exact same stuff I was doing, so was love at first sight 🙂

@tony.kay: I randomly sampled a few snippets of the getting started videos: please corrrect me if I'm wrong: (1) those videos don't start from scratch (2) those videos jump into an existing code base

@qqq I'd like to know if the getting started videos seem to advanced for a cljs dev that has no Om Next

The intention was for them to actually target such ppl

and yes, it is an existing code base, but not a big one

crawl -> walk

this is not a comment on the videos, but at this point, I actually find the "untangle reference manual" to be better written than the "untangle devguide"

@qqq I’m planning on working on server documentation on the weekend and/or next week, so I’ll make sure I add code samples to that while im there

@adambros: if I can find the following 1 example, I can do the rest on my own

so the simplest untangle example is a counter ;;

current count is: N
[ click this button to increment N ]
now, the simplest example I would want -- is one where N is stored remotely

I can't find this example anywhere; is this example available?

i dont think i’ve seen that example, but the gist of is that you would do :remote true in the client mutation, and implement a server mutation to update the server state

ah sorry, you also want index=7, "server basics"

looks like I really should watch these videos 🙂

personally i like watching videos at 1.5x speed, but that can be too fast if you arent used to it

the one thing that I hate about screen casts

is inability to random access the code

now, to see a particular page of code, it's "hmm, let me guess which minute/second time stamp was this on the screen at" ?

someone needs videos that are synched with git tags; so at any point, I can say "in video X, at time MM:SS", what does the git repo look like?

@tony.kay : i watched through the first 4 videos; info per minute is like 100x higher than readig devguide

not sure if this is due to video being awesome, or due to learning first from devguide

@adambros : it also appears, starting with video 5, that these videos have precisely the git tags I wanted 🙂

👍 1
😆 1

it is a graph database, and idents are the graph edges. The table entries are the nodes

There will be some top-level keys that do nothing but act as roots of trees

{ :root [:table 1]
  ...tables...}

You can have any number of top-level keys that point into your graph

but the depth of the overall db data structure is 2

the depth of the graph is potentially infinite (recursive loops)

the :person/mate example

The UI query traverses this graph to produce a data tree for the UI

so all of the keys in the root query will appear as top-level keys in your db

they are the roots

@tony.kay: alright, so we squint, untangled state = really a db, since it's a COLLECTION of TABLES (with keyword = table, id = pointer to row of table) ui components = (data->dom (some-query)) because ui components have two parts: (1) what do I need to render this UI (the query part) (2) how do I render the data (the data->dom) part is the above correct?

it's really quite simple...just different

alot of the om/dom + the datomic-pull syntax really hides this

To anyone interested in Untangled and related tech: I'm going to be at clj west. I'm willing to do an Unsession around anything there is interest in. Open to suggestions. Let me know.

@qqq I wouldn't say it hides anything. It exposes exactly what is needed and no more. A query + a render + a way to understand where in the database a given UI component's data lives (ident)

It is true that you cannot get to "graph db" from just that

@tony.kay: by "hide" I meant in the sense that a neighbor playing loud rock music "hides" the beethoven sonata you're trying to listen

the idea is still there, but the first thing a n00b sees is the datomic pull syntax / om/dom stuff

of course. It is an unfortunate truth of abstract concepts: knowing what/how/why of something is not self-evident

I can show you syntax for Haskell Monads, but you'll be reading for a few weeks to "get it"

I'm coming from regent/re-frame, and basically everyone told me how complicated om/next would be -- and in many ways, I don't disagree with them; this really unfortunately makss the elegance of untangled

tony.kay: actually, I've written monad transformers myself 🙂

Rich Hickey said it best: as developers, many of us are too enamored with "easy". Can I start using it right now and not have to think? Is it already familiar?

Good developers are open to learning and the wider context of simplicity, which is not necessarily always easy

well, it is never initially easy...cause it is new/foreign

but "complicated" is the wrong word

om/next is less approachable

Untangled aims to make that better

but you still have to step up and learn somethin' 🙂

this is getting 'preachy' 🙂

I do think the docs can be improved a bit though; it wasn't until I got the untangled todomvc server/client example working that I realized "untangled makes it worthwhile to learn om/next"

Feel free to make suggestions. But make sure you've looked over what's available. I've done a lot of work on the docs/videos

or perhaps you meant the Om docs in the Om project.

there is that (problem)

You have visited the Untangled website/docs/videos, right?

@tony.kay: I'm curently working through the untangled devguide

I can't comment on the other resources; but for the dev guide, it

's not until I get halfway through that I come across something that can't be easily done in re-frame

I believe that if the full client/server power was shown off earlier, there'd be more converts

Yep: data-driven wins once you go beyond simple examples. But that is the problem: you have to get to the "in the large" problems before it pays off...but then, that is what most of us are building: stuff that gets large.

so keeping someone's attention long enough to get there is hard. That is a good observation, though. More advocates stressing the full-stack story.

or even the in-the-large story. You can make a mess in anything. As things get large, better abstractions lead to an ability to keep things simpler. Still, people still manage to tangle up Untangled 🙂

@tony.kay: I agree that untangled is the right framework. I also think that more users = more libraries, more bug reports, faster bug fixes. In this sense, a way to make people immediately aware what untangle offers over other frameworks would be beneficial.

Always open to suggestions/contributions. I have a feeling it is advertising some of the stuff we already have as resources (e.g. videos) in a venue that gets more visibility

I'm not much of a sales guy

I'm trying to get around this problem: start from scratch ==> people have to go through om/next + datomic/pull before starting to see power of untangled start with existing codebase ==> have to pick boot vs lein, cursive vs emacs, etc ... so some group of ppl put off, and it becomes fragile to maintain

yeah, we already decided lein+cursive. Most widely approachable...and with nREPL support the emacs ppl are covered.

existing code base: we have the cookbook, todo mvc, template, and videos

btw, the todo mvc is out dated, it uses a version of data-fetch that doesn't work wil the devguide

hmm, maybe the docs are fine, and the problem is I'm using emacs + boot 🙂

data-fetch API has had additions (and deprecations) but I don't think any of it has been removed. But worth checking

I have the weirdest bug: ` (. js/console log (= (om/get-query Ex2-Child) [:id :n])) ;; returns true (query [this] [{:items [:id :n]}]) ;; works fine (query [this] [{:items (om/get-query Ex2-Child)}]) ;; fails to extract data

Maybe I should suggest a clj-west Unsession on "Why Om Next/Untangled?"

compare and contrast against other popular options

http://www.parens-of-the-dead.com/ <-- this is what switched me from vim to emacs

I love that series

IntelliJ + IdeaVIM gets you most of the way there (on editing at least)

I don't know if the untangled videos hit that level -- as I don't use cursive.

multicursors, structural editing, VIM bindings, etc.

does (query [this] QUERY) have an equivalent for SELECT * ?

I want a QUERY which just selects EVERYTHING

(query [this] ['*])

you need the quote since * is a symbol

but that won't follow joins

(om/get-query Ex2-Child) // returns ['*]

(query [this] [{:items ['*]}]) // returns {:items [{:id 1, :n 3} {:id 2, :n 9}]}
(query [this] (om/get-query Ex2-Child)) // returns {:items [{:child/by-id 2} {:child/by-id 2}]}
I'm completely confused

um, neither of those is right 🙂

(query [this] [{:items (om/get-query Ex2-Child)}])

makes more sense

ex2-child wants all of its properties

some other component wants to join through other to (one-or-many) Ex2-Child

sorry, (was copying/pasting from other machine) for the second one, I meant to write

(query [this] [{:items (om/get-query Ex2-Child)}])

which I believe is the same as what you wrote

that is reasonable

but I'm getting different results

one of them returns the idents, the other one resolves the idents

this is section G, mutation exercises

a join should use the query of the thing being joined to

would a less patient person say "the problem is you don't understand datomic pull syntax" ?

there is nothing to the syntax 🙂

this is an Om-ism

the get-query adds metadata to the query. So when you compose queries using get-query it augments the query data structure

when you manually type it you don't get the metadata

are you saying "the existence of metadata changes the way the query is evaluated" ?

so, I don't have enough context (and I have to leave to meet someone, so I cannot take the time to establish that context), but yes: the metadata affects how things work. Normalization in particular

it is how normalization gets done. If you don't have it, your initial database gets hosed (not normalized)

can you point me at docs to read on how metadta normalization, and querying works?

clearly I'm not understanding this part

David Nolen's tutorial on normalization on the Om wiki. The dev guide certainly tries to explain it. My clojure west unsession (youtube from last year).

okay, so this is a Om query issue, not an untangle issue

Untangled modifies nothing about how the queries and normalization work.

from a component/default database format perspective. Untangled adds a lot of the glue.

The dev guide sections on app state database and queries is possibly the most approachable source...but you've done those already

well, clearly I didn't understand them fully

I'll look at them again

The gory details of how the algorithm works: thats the Om tree->db function.

let me ask you one more question, without proviidng context:

should: (query [this] ['*]) and (query [this] '[*]) be equivalent (note the order or ' vs [ ). If not, why not?

I do not (immediately) see a reason for a difference. But quoting is one of those weird things

I never use that query syntax, so I cannot speak to reality 🙂

gnight 🙂

thanks for all your help; take care

okay, so I've just read through parts of the devguide a second time; I don't see this part: where is the claim that: om/get-query adds metadata and may effect how the query is run stated ?

It is talked about quite a lot in various docs. As long as you always use get-query for subqueries in your components I don't think you will be hurt too much. I just did a google search: 'om next query metadata' - plenty of info there.

The first two links are to parts of the om wiki, which I've already read.