I'm having some trouble getting CodeMirror to work in a Om Next component. I've not used React except with Om, so I'm not sure that I'm doing things correctly. I've tried creating the CodeMirror editor inside of componentDidMount using (dom/node this) but I get a CodeMirror error in the console. (I'm using CodeMirror through cljsjs.) Does anyone know if this the right approach?

@arohner If you explicitly pass nil as the props, it doesn't matter what the child's query is. Rather than do that, you should pass in the part of the parent's props which correspond to the part of the parent's query that's (om/get-query ChildComponent). If the child queries for an ident/link, that part of the parent's props (the part that you're about to pass in as the child's props) will have been read from the root of the app state.

That is, [[:foo _]] and [{:bar [[:foo _]]}] both read the :foo key from the root of the app state, but one puts the value it finds at [:foo] in the props and the other puts it at [:bar :foo].

right, I mostly get how it’s supposed to work. What I saw yesterday though looked like a bug / weird behavior. I was passing nil to a component. On first render, its props were nil. After transacting :foo, it rerendered with :foo, though I don’t understand why

@arohner Oh, gotcha. At that point, the indexer knows that that component is rendering :foo, so when :foo needs to be re-read, it'll re-render that component with new data without rendering its parent. That's incremental rendering. It's not obvious (and possibly not officially documented yet), but it's a neat trick. https://anmonteiro.com/2016/09/om-next-internals-incremental-rendering/

seems like that violates an invariant? If it didn’t render :foo the first time, why render it after a transact?

if you have a query you cannot pass nil

I haven’t followed all the details of what you are saying but the query is a contract

Ok so about Om and specs.

I love the idea of uniting specs and queries

I guess I need to think further about the implications of that. I'm still more familiar with "Om previous" so that may cover more of the cases than I realize.

I wanted to use specs to clarify all the cases a component has to handle, like: no data, some data, remote data plus local incomplete state with a validation failure, etc.

@asolove all of that sounds good except “remote data"

we never want to talk about that

Can you tell me what the right nomenclature is for distinguishing "persistable, valid, complete" data versus in-process data, like maybe an address form where someone has typed in only the street number. That data inhabits the same component as a "real" address, but it isn't yet safe to persist it, pass it to functions that expect a valid address, etc.

@asolove the point is components don’t care

that’s someone else’s problem

in om.next this is hidden from the UI via parse

thus there’s no reason for these concerns to infect queries

Hmm, scratching my head about this, which means I need to go back and read some more om next code.

Thanks for challenging that, think it'll be profitable for me to understand what you're saying.

om.next is about delivering the illusion to your UI components that asynchrony is non-concern

persistence is a non-concern

all of this is handled by your parsing logic

That part I understand, but I do still have in my head a distinction about local state that isn't ready to be shown to anything else in the system.

right, I’m just saying you can do whatever you want

it’s just not ever going to leak into your UI

yeah

there’s a whole other thing around tempids for this problem as well

so you can construct completely transient complex data and commit that at your leisure

and the backend can communicate id transition

more reading for me

Is*

@currentoor interesting. try this:

(extend-type om.tempid/TempId
  bidi/PatternSegment
  (matches? [_ s]
    (instance? om.tempid/TempId s)))

(extend-protocol bidi/ParameterEncoding
  om.tempid/TempId
  (bidi.bidi/encode-parameter [tempid]
    (str (.-id tempid))))

(def routes ["/" {[[(om/tempid) :id] ""] :tempid}])

cljs.user> (def x (om/tempid))
#'cljs.user/x
cljs.user> (bidi/path-for routes :tempid :id x)
"/2ed7c229-9d31-4b2f-bf24-cf23f2d8c52e"

(I assume you're only using this for path-for, I don't think it makes sense for match-route. Right?)

My trick above is to use a bogus instance of om.tempid/tempid

@anmonteiro thanks! Why wouldn’t it make sense for match-route?

hrm

because you usually want to match a route against a string (the URL)

not against an instance of tempid?

I’ve got a function that I use, looks like this

(defn url->route
  "Converts a url to a route structure. Uuid strings are converted to om tempids."
  [url]
  (let [{params :route-params :as route} (bidi/match-route routes url)

        parsed-params (u/mmap (fn [[k v]]
                                (cond
                                  (re-matches id-regex v)   [k (long v)]
                                  (re-matches uuid-regex v) [k (om/tempid (uuid v))]
                                  :else                     [k v]))
                              params)]
    (assoc route :route-params parsed-params)))

exactly

you're using match-route on a string 🙂

it's never going to be a tempid thing is it?

not sure I follow, ideally I would not have to call (om/tepid (uuid v)) in the url->route function.

(bidi/match-route routes (om/tempid))

^ just doesn't make sense

right

so you need to coerce it to a tempid from the param string you get

but path-for can be made to work, as in my snippet

I’m saying (bidi/match-route routes ”/dashboards/eaf9396e-c840-4a70-aa68-36e7b8bc6177/edit”)

but it returns a map with a tempid rather than a string

@currentoor and what I'm saying is that you have no tempid in that string

so the param map that bidi returns is always going to have string values

even in the case of regexes: [[#"\d+" :id] ""]

you don't get maps with number values

they're strings

because it's what bidi matched from the input string

but then we would never be able to have numbers or uuids returned from match-route?

maybe that is the case?

can you produce an example that contradicts what I'm saying?

i might be mis-remembering, i’ll check

@currentoor happy to be proven wrong! let me know if you find something, I'm curious now

Yeah, pretty sure bidi can coerce params in match-route: https://github.com/juxt/bidi/blob/master/test/bidi/bidi_test.cljc#L193-L194

@anmonteiro this is what i meant

didn't know about this, I'll be using this very soon 🙂

@currentoor so it seems you need to override this? https://github.com/juxt/bidi/blob/master/src/bidi/bidi.cljc#L153

yeah it’s nice, but i’m not fancy enough to figure out how to make it work with om/tempids

I'm heading to bed now, but I'm happy to help you figure this out tomorrow if you haven't already

yeah that would be freakin awesome!

thanks

let me know if you make any progress, I'll read it tomorrow 🙂

will do!

it does seem, though, that bidi is lacking in extensibility to user defined functions

or it's there but just not documented anywhere

i did see this

https://github.com/juxt/bidi/issues/87

or maybe it's possible, even, to do what you want but there's just no docs on how to

yeah… fun to figure out though

i gotta go, i’ll try later

thanks!