Clojurians Log v2

@carter.andrewj would you be happy to post a gist of some of your working code? i'm still tinkering with recursive queries myself

like, how do i insert into my atom in a way that makes it easy to recurse over? that's been my question lately

hi, is there a way to access the state history or to get the uuids produced by a transaction in om.next?

In thanks for all my learning here, I thought I'd contribute this gist in case it helps anyone wire up a component to D3 using refs: https://gist.github.com/rgm/7f2771a605956c17e5fb8c7409a7098a

I'll do approach two (just using D3 for data transformation and doing the DOM manipulation through React) sometime soon.

though that does seem easier to figure out given that from that approach the boundary between D3 and React is cleaner ... they're not invading each other's territory.

@jduenas not directly for now, but work is planned. you can use :tx-listen though, which will give you the "old state" and store that yourself

@anmonteiro thanks! will do

@sova Would be happy to (but currently snowed under fixing a newly-uncovered bug in our analytics pipeline) - Will hopefully get around to it later today, but in case I don't, please do remind me about it tomorrow 🙂

folks, a little bit strange question, but I'm exploring that space now, so the question is: after years of Om and other React/virtual-dom/etc. based ClojureScript frameworks being here, do you think Om's decision to represent component as a type implementing Om interfaces is good one?

from the point of view of leveraging language features and composability and extensibility

in comparison with other solutions, i.e. Reagents function form-1 and form-2 and metadata

do you had any profit from this decision in real-world projects? Like implementing for component other interfaces and having clean code as result

@ul that decision was dropped on Om.next, so for the React interfaces itself this is not the case anymore, in Om.next we still support other interfaces (like IQuery and Ident, and others) and for that I find it useful to have, one example is the Untangled framework that adds IInitialState, and I personally had created some interfaces myself and I find it useful when you need some specialized behavior

@ul We’ve benefited from Om.Next’s static protocols quite a bit. We further extend our components with a protocol that looks like

(defprotocol Routing
  (url->state [this props])
  (state->url [this url]))

We use this protocol to ensure our URL is in-sync with our app-state, and to provide the initial app-state on page load.

Hi, are there plans to extract the om.next parser from om? I think it could be useful for other frameworks

Thanks for response! So, having component as a type is good because we could extend it without using HOCs and all that ceremony with wrapping and re-wrapping component and proper passing through of props?

Because I feel that for example Reagent components being functions doesn't compose in such nice ways as functions do (if I want full-blown component composition, of course, pure rendering functions are pure rendering functions and compose nice).

@gardnervickers That's a pretty nifty solution there - is the code available somewhere for me to peruse (and, with permission, imitate)?

@carter.andrewj The code is just the protocol 😄

I’ll see if I can make a sample devcard soon.

@jeroenvandijk any reason for not including Om.next just for that?

@gardnervickers Cheers 🙂

I'm trying to build a recursive parser, and it's a bit of a pain that the parser can't accept a query of [*]. Would the project be open to a PR that would make that query work?

@peeja what would the parser dispatch key be in that case?

Probably '*

that’s not a valid key according to the spec though

(parser/query->ast '[{:foo [*]}]) ;; => {:type :root, :children [{:type :join, :dispatch-key :foo, :key :foo, :query [*], :children [{:dispatch-key *, :key *}]}]}

That's what happens today

symbol->ast turns a symbol into an AST node with no :type

A symbol should be a valid dispatch key: https://github.com/omcljs/om/blob/master/src/main/om/next/impl/parser.cljc#L34

Of course, that's currently meant for :calls, but still, it's valid

Oh, and for ..., but ... never hits the read because the parser handles the recursion