Fork me on GitHub
#om
<
2015-09-23
>
dnolen00:09:33

presented with little explanation, but I’m pretty excited about where this is going - feel free to ask questions https://github.com/swannodette/om-next-demo

dnolen00:09:52

it includes some things I’ve never talked about before, a sketch on how read/mutation model can be shared between Client Server a la Falcor (this is a huge IMO)

dnolen00:09:27

and it shows how trivial is to sync (like zero code), Datomic makes all of this quite trivial

dnolen00:09:49

but the model is flexible enough to be purely clientside (i.e. DataScript) or attached to microservices a la Netflix

akiva01:09:45

This makes me want to jump into developing an Om Next app just to do it.

dnolen01:09:40

@akiva ha, not quite there yet - I’m thinking I will probably release an alpha (with copious documentation) so people can help work out the kinks

akiva01:09:58

Oh, I know. Just getting excited for it.

dnolen01:09:04

one the really cool things about the new design is how much you can push mutation / reaction logic into the server

dnolen01:09:30

pretty sweet for internal apps where you just want to eliminate the inevitable accidental complexity of doing everything on the client

dnolen01:09:37

(and really twice since you still have to deal w/ the server)

akiva01:09:58

Definitely going to bring some welcome flexibility.

dnolen01:09:41

yeah it’s one read / mutation model you can decide how “far away” you want it to be. Again, all credit to Falcor.

afhammad08:09:09

@dnolen Do you foresee any difficulties with a SQL backend other than the slightly more complex parsing to SQL?

lukemorton09:09:50

What's an ideal build/development stack for om/om.next?

lukemorton09:09:33

Which tools lein/build/figwheel/etc.? How can I build sass? Wondering where to start.

afhammad09:09:31

@lukemorton: https://github.com/plexus/chestnut might be a good start, sets you up with lein, figwheel, sass and a backend

lukemorton09:09:18

Oh wow that looks useful! Cheers @afhammad

lukemorton09:09:44

Looks like a sensible place to start. Was getting in a twist working out whether boot or lein was better.

plexus09:09:38

@lukemorton chestnut might be getting behind a bit on latest developments, but at least it's a complete and beginner friendly solution

plexus09:09:14

Make sure to check the docs, and get on the chestnut mailing list if you need any help

lukemorton09:09:36

Yeah, huge amount of boilerplate though!! To be fair though I just want to try out om and get it live somewhere so cheshnut is perfect.

afhammad10:09:22

@plexus: out of interest, what developments are you referring to?

plexus11:09:03

there's just a bunch of things that have been happening that I haven't had a chance to have a good look at. I'd actually appreciate input in this area on how to improve and evolve Chestnut. Figwheel now comes with its own repl support. Maybe we should be using that? OTOH last time I checked that doesn't work with CIDER, but is weasel still the best option? Another thing, we're including a JS test runner for phantom, I would like to see that go and use doo instead.

plexus11:09:48

om.next seems to be shaping up nicely. Should there be a chestnut.next?

plexus11:09:36

the current setup for launching figwheel from the REPL is also a bit hacky, we're duplicating stuff from project.clj which confuses people

afhammad11:09:01

defo agree on the last one

minimal11:09:44

I find the figwheel repl the most reliable these days

plexus11:09:02

the alternatives are parsing it out of there ourselves. Also a hack but at least it's in one place, or launch figwheel with lein-figwheel, instead of from the REPL

plexus11:09:00

I personally don't have all that much RAM on my laptop (4GB), so I try to avoid launching extra java processes. Right now we have figwheel, jetty, repl all in one process which is cool

dnolen12:09:05

@afhammad: so this is something that people have misunderstood a bit, there really isn’t any “parsing to SQL"

dnolen12:09:39

the router (what’s currently called the “parser”) just dispatches on keys. You can return whatever you want however you want for a key.

afhammad12:09:59

@dnolen: ah, I did misunderstand that, thats simple enough. When you said Datomic makes it more trivial, was this in relation to the convenience of :<namespace>/<name> naming and that queries as data are easier to construct?

dnolen12:09:44

@afhammad: Datomic’s support for pull syntax just means you can send off a whole subtree to Datomic to takeover

dnolen12:09:57

so I suspect Datomic backed Om Next apps will be more “graph-y"

dnolen12:09:18

and everyone else will be perfectly happy with more “shallow” designs a la Falcor.

afhammad12:09:01

got it, thanks.