Clojurians
#om
<
2017-04-10
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

sova01:04:01

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

sova01:04:26

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

jduenas05:04:54

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

rgm05:04:55

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

rgm05:04:31

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

rgm05:04:46

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.

anmonteiro05:04:30

@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

jduenas07:04:22

@anmonteiro thanks! will do

carter.andrewj12:04:11

@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 :slightly_smiling_face:

ul13:04:02

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?

ul13:04:53

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

ul13:04:39

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

ul13:04:12

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

wilkerlucio14:04:20

@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

gardnervickers14:04:23

@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]))
Which our root component uses to build up a URL or app-state by calling it’s children.

gardnervickers14:04:33

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.

jeroenvandijk14:04:03

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

ul15:04:22

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?

ul15:04:47

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).

carter.andrewj15:04:53

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

gardnervickers15:04:23

@carter.andrewj The code is just the protocol :smile:

gardnervickers15:04:02

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

wilkerlucio17:04:44

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

carter.andrewj17:04:54

@gardnervickers Cheers :slightly_smiling_face:

peeja20:04:02

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?

anmonteiro20:04:36

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

peeja20:04:55

Probably '*

anmonteiro20:04:11

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

peeja20:04:23

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

peeja20:04:29

That's what happens today

peeja20:04:55

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

peeja20:04:10

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

peeja20:04:09

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