Clojurians
# om

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

sova 04:29: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

sova 04:29: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

jduenas 08:12:54

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

rgm 08:38: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

rgm 08:40:31

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

rgm 08:41: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.

anmonteiro 08:54: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

jduenas 10:49:22

@anmonteiro thanks! will do

carter.andrewj 15:47: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:

ul 16:29: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?

ul 16:29:53

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

ul 16:30:39

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

ul 16:32: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

wilkerlucio 17:24: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

gardnervickers 17:41: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.

gardnervickers 17:43: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.

jeroenvandijk 17:53:03

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

ul 18:22: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?

ul 18:23: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.andrewj 18:54:53

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

gardnervickers 18:55:23

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

gardnervickers 18:56:02

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

wilkerlucio 20:14:44

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

carter.andrewj 20:15:54

@gardnervickers Cheers :slightly_smiling_face:

peeja 23:53: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?

anmonteiro 23:55:36

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

peeja 23:55:55

Probably '*

anmonteiro 23:56:11

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

peeja 23:56:23

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

peeja 23:56:29

That's what happens today

peeja 23:56:55

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

peeja 23:58:10

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

peeja 23:59:09

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