Fork me on GitHub
#clojurescript
<
2015-06-14
>
mfikes00:06:48

Cool: With the new :module-type :commonjs feature for :foreign-libs, you don't need to specify a :requires vector—the dependencies are derived during CommonJS processing!

dnolen01:06:31

@mfikes right as they are proper Closure modules

borkdude11:06:45

I'm looking for a guide which tells me how to do prerendering with a clojure/clojurescript/reagent application + how to combine the server side + client side routing story

borkdude11:06:54

I guess the term for this would be isomorphic, so I'm looking for a ready to go example of an isomorphic cljs+react project

andrewmcveigh11:06:35

@borkdude: I’ve kinda done this with clojure/hiccup, om/sablono and a couple of macros. The code lives at my previous employer, so unfortunately can’t share it.

andrewmcveigh11:06:51

The macros weren’t much though.

borkdude11:06:40

@andrewmcveigh: do you end up duplicating routes on the client and the server, or do you only define one compojure route "/" and pre-render from there?

andrewmcveigh11:06:45

@borkdude: I used bidi for routing, using a EDN-only route specification, for both client/server

andrewmcveigh11:06:24

The routing essentially lived as part of a “config” namespace

agile_geek12:06:33

This might be a bit more of a question for the #C053AK3F9 channel but what are pros & cons for Reagent vs Om?

borkdude12:06:14

@agile_geek: Reagent is easy to understand for already experienced Clojure(script) developers, since it re-uses the concept of atoms. Om forces you more or less to use one atom for the whole application that you can access by using cursors + API built around that.

borkdude13:06:02

I've tried out the demo app in this isomorphic clojurescript blog post: https://www.paren.com/posts/isomorphic-clojure-part-1

borkdude13:06:15

it seems promising, although very slow

agile_geek14:06:11

@borkdude: Thanks for that. So are there use cases that favour the use of one over the other?

borkdude14:06:30

@agile_geek: I think it's largely personal preference. I favor Reagent because I like the simple approach.

borkdude14:06:45

@agile_geek: also Om is in a transition towards Om.next and they may not be compatible, so it may be worth waiting for that if you're choosing Om. Don't know the details. Ask @dnolen

dnolen14:06:03

not worth waiting

dnolen14:06:08

the current Om model isn’t going away

dnolen14:06:16

and Om Next is likely to be under dev for months

dnolen14:06:39

they will also coexist, and there will be some kind of bridge

dnolen14:06:56

there are far too many massive Om applications to introduce breakage at this point

borkdude14:06:08

@agile_geek: Maybe if you want to be able to recover your entire app from one state value, that is where Om really shines, because it (almost) forces you to work that way

agile_geek14:06:19

@borkdude @dnolen: cool. I’ve looked briefly at Om but not at all at Reagent. Always hard when Clojure is not my day job. I think I’ll get some more OM under my belt then take a look at Reagent.

borkdude14:06:29

@agile_geek: you'll read through the Reagent documentation in under 15 minutes

agile_geek14:06:17

@borkdude: I read fast but assimilate very, very slowly.

dnolen14:06:31

@agile_geek: either will probably get the job done.

borkdude14:06:37

@agile_geek: there's not so much too assimilate, trust me on that one simple_smile

markstang14:06:48

@agile_geek: I prefer to see the "app state" as more of a database

agile_geek14:06:24

@borkdude: Isn’t much Clojure syntax but it’s taken me 19 months so far and I’m still not there 😉

borkdude14:06:01

@agile_geek: things take longer when it's not your day job, I feel with you on that one

jackjames14:06:45

i don't think it's accurate to characterize reagent as "the simple approach". om and reagent make a different set of tradeoffs. om's documentation is not substantially less approachable in comparison, and i don't consider it to be complex overall, nor complex in any specific area where it could possibly achieve the same with a simpler approach.

agile_geek14:06:21

@borkdude and takes longer as u get older!

borkdude14:06:36

@jackjames: Yeah, simple is not the right word for it. My personal experience has been that Reagent has a less steep learning curve than Om. There are also less concepts to understand.

borkdude14:06:53

Maybe other people have different experiences. There's no absolute way of saying which approach is better, easier, etc. It is about tradeoffs, correct. Both are excellent libraries. Rum is also worth checking out, but I don't have any experience in it.

jackjames14:06:21

@borkdude: yep, when you put it like that, i agree completely

borkdude14:06:04

@jackjames: simple is an overloaded word in clojure, I should avoid it completely simple_smile

borkdude14:06:33

In all approaches it may be best to first do the React tutorial so you know what happens inside, sort of.

agile_geek14:06:26

OK, Thanks for the help @borkdude @dnolen @markstang @jackjames. Food for thought. As usual, I seem to have picked the one with, arguably, the steeper learning curve to learn first!

borkdude14:06:24

@agile_geek: to make your choice even harder, there's also http://hoplon.io/, which is not React-based.

agile_geek14:06:07

@borkdude: Given I’m using this on hobby projects I think I’ll stick to React based libraries for now as both Reagent and Om seem to have some traction in the community and I can ask nice people like you and @dnolen for help simple_smile

borkdude15:06:06

@agile_geek: Both Om and Reagent also have cookbooks (just google) and mailing lists

borkdude15:06:36

about pre-rendering: actually it would be enough if I could just fool google with some pages that contain relevant content, without any css

borkdude15:06:53

it may be less work

borkdude15:06:20

Would it be sane for SEO if I would render a page using certain keywords at /item/1 with a meta refresh to #/item/1 ?

borkdude15:06:08

probably the #! way is better

borkdude15:06:03

sorry for rubber ducking this channel

dnolen18:06:36

nothing working quite yet but can now point the ClojureScript compiler at cljs.analyzer and generate JavaScript simple_smile https://github.com/clojure/clojurescript/commit/20d120731aa3063dc7ccf43dcd7f0ccd81e9acac

andrewmcveigh18:06:28

@dnolen: What’s left to do now then? Can’t be too much.

dnolen18:06:08

@andrewmcveigh: actually there’s quite a lot to do for it to be usable. However for the minimal viable thing, i.e. read forms and generate JavaScript - just need to port cljs.compiler, make macros work, fix the bugs.

mfikes18:06:24

One small step for analyzer... :)

shaunlebron23:06:15

@dnolen: should there be a public API for cljs.repl, like everything else in the quick start? i.e. cljs.repl.api/repl, cljs.repl.api/node-env, cljs.repl.api/nashorn-env, etc

shaunlebron23:06:36

the generated compiler API reference was omitting the important cljs.repl stuff. I suppose I can add an exception, but it just brought up the question of whether it should be in a public api or not