Fork me on GitHub
#untangled
<
2016-07-26
>
currentoor15:07:52

We launched our public beta today built using Untangled, gave the framework a shoutout in the comments. https://news.ycombinator.com/item?id=12165682

currentoor15:07:34

@tony.kay and friends thank you so much for making this modern lisp stack totally accessible!

shaun-mahood16:07:32

@currentoor: I might be an idiot but I can't seem to get to your site from the hacker news link, found it on google though. Is the entire thing Untangled?

currentoor16:07:06

@shaun-mahood: oh it's silly that the HN post doesn't link to the actual product, I think one of our marketing people posted it.

currentoor16:07:34

The entire reporting product is untangled-(client, server, datomic, spec)

currentoor16:07:48

We originally built the prototype in vanilla Om next. Then started with Untangled in April.

shaun-mahood16:07:14

@currentoor: Very cool. I'd be very interested in any info you can share about the graphing and dashboards in there, they look excellent.

currentoor16:07:03

@shaun-mahood: I'm happy to answer any questions. We're planning on writing a blog post going over our experiences.

currentoor16:07:01

we wrote some components to wrap this library http://c3js.org/

currentoor16:07:04

for the charts

shaun-mahood16:07:40

@currentoor: Oh cool, was it nice to work with once you wrapped it?

ethangracer16:07:12

@currentoor: I’d sign up for a free trial to play around if I could! looks fantastic

currentoor16:07:27

@shaun-mahood: yeah it was pretty straight forward

jslavin16:07:39

@currentoor: Are you using d3 for your graphics?

currentoor16:07:17

we used this to component as the base to build all our other charts

currentoor16:07:36

@jslavin: we're using C3 which uses D3 under the hood

currentoor16:07:50

@ethangracer: thanks! We couldn't have done it without you guys!

jslavin16:07:34

@currentoor: Great job, we at navis are excited to see others using the libraries

shaun-mahood16:07:55

@currentoor: Thanks, looking forward to the blog post. I bet it will be really, really nice to maintain.

kenbier16:07:09

@shaun-mahood: it was pretty straightforward to wrap, we used some lifecycle examples that looked very similair to what @tony.kay used for his d3 react component (i think that was posted on the om channel awhile back).

anmonteiro16:07:09

@currentoor: cool stuff, looks good! I’d love to see those chart components open sourced

anmonteiro16:07:17

I understand that there might be politics involved, though 🙂

currentoor16:07:22

@anmonteiro: @kenbier built them, maybe he convince our CTO

kenbier16:07:15

@anmonteiro: i cant make any promises, but i can ask 🙂

anmonteiro16:07:35

Just rooting for a wider adoption of Om Next. Pretty sure everything we can get out there to feed the (still tiny) ecosystem is very welcome

currentoor16:07:19

yeah that would be cool, we certainly had more fun with this stack than any other we've worked with

shaun-mahood16:07:17

Out of curiosity, was this the first Clojure project you have undertaken at the company, or was there already some Clojure traction?

therabidbanana16:07:24

We already had some Clojure parts in our stack (for example the underlying metrics service we're grabbing most of our data from)

therabidbanana16:07:38

First full-stack Clojure project here though

shaun-mahood16:07:40

Very cool, I love that there are companies willing to go all-in like this.

therabidbanana16:07:46

Well, it certainly still took a lot of pushing from @currentoor to get us to try it. 🙂

currentoor17:07:12

@shaun-mahood: yeah i had to sell my soul and take a second mortgage on it get this project approved!

tony.kay17:07:21

I love that you guys pushed a public commercial product beta out in 4 months. That speaks volumes I think.

therabidbanana17:07:54

Initial traction was gained by getting a commitment to let us try a week long spike and see how far we could get. We were able to get a workable enough demo that it seemed like a viable solution

tony.kay17:07:22

I think you guys should announce on the #C06DT2YSY channel as well. I think it could help the general crowd of om-next interested users to raise an eyebrow towards Untangled as a simplification for getting going.

tony.kay17:07:20

I think you've beat everyone else to the punch on having a commercial om-next full stack app...including us 😕

tony.kay17:07:54

(actually we do have an internal beta going on with real clients, but it isn't public facing)

therabidbanana17:07:22

Yeah, we were in a private "alpha" for a month or so

currentoor20:07:30

Is there a way to query for all the entities of a particular ident? Like [:dashboard/by-id *] vs [:dashboard/by-id 1]?

tony.kay20:07:06

[:dashboard/by-id]

tony.kay20:07:11

will give you the entire map

tony.kay20:07:31

if I understand your question correctly

tony.kay20:07:07

then just use vals

currentoor20:07:24

@tony.kay: that'll work in a query?

currentoor20:07:33

cool that makes sense i suppose

ethangracer21:07:53

@currentoor: that’s one of the cool untangled nuggets — if a keyword is not part of a join, we assume it’s at the top of the app state and we return whatever is at that key

anmonteiro21:07:59

FWIW, it’s what Om will do too if you call db->tree, which is what Untangled uses, IIRC

anmonteiro21:07:08

correct me if I’m mistaken

ethangracer21:07:04

interesting, we treat it as a separate case in our custom read untangled.client.impl.om-plumbing/read-local, but maybe we don’t have to

anmonteiro21:07:44

@ethangracer:

cljs.user> (om/db->tree [:foo] {:foo 42} {:foo 42})
{:foo 42}

anmonteiro21:07:10

you treat it differently because the parser dispatches on top-level keys so you don’t really have the [:foo] query

anmonteiro21:07:23

so what untangled does def makes sense

ethangracer21:07:42

@anmonteiro: right, I forgot the parser strips the key from the query. makes sense