Hey everyone, I just started a 'Basics' section in Reagent Cookbook. Hoping this can build over time and be curated by the community through PRs and issues. So if you have something you'd like to add, please submit a PR

Hi, I wanted to find out how you go about getting data from db and passing them to reagent component. I've got a bunch of functions in src/myapp/db/core.clj would you keep the db functions there or have them in src-cljs e.g. src-cljs/myapp/db/core.cljs

@konradszydlo: is the db on the server side?

yes.

at the moment it's a pet project and I have total control over structure.

I guess this is a good starter suggestion - http://www.luminusweb.net/docs/clojurescript.md#ajax

That is using cljx-ajax with a REST API on the backend

Or if you want to be fancy you can try websockets/sente, but ajax is probably easier to start out with

@konradszydlo: usually I do it like this, using compojure/liberator + cljs-http: https://github.com/borkdude/domcode-cljs-react

@jaen: interesting idea. This way I can separate parts of app before it becomes one monolith.

thanks @borkdude

@borkdude: cljs-http is the one with core.async, yes?

@konradszydlo: it's how most (javascript intensive) web applications work.

@jaen: right

@konradszydlo: after you get the basic setup working you might want to think about using transit for serialisation instead of JSON or something, this is usually less painful since it keeps types as opposed to JSON. If you decide to you might want to take a look at - https://github.com/ngrunwald/ring-middleware-format

@jaen @konradszydlo why not just keep it all edn

Not sure, I made the jump straight from JSON to transit, didn't do any Clojure that required serialising things in the before transit era. Is there any other reason that makes using EDN preferable to transit apart from not wanting another dependency?

@jaen: don't know, I've always used EDN

And I've always used transit, so I guess that's just a question of habit I suppose.

transit is good when you want to go from one representation to another

@jaen: According to cognitect, Transit is much faster on the (browser-) client than EDN. Makes sense. But on the other hand Transit must be slower on the server?

I haven't seen any benchmarks, but that's quite possible, it be hard to beat something that's been around for quite a while, like Jackson

@jaen: Especially because of the native browser support for JSON :-) David Nolen wrote more than a year ago: "For Clojure & ClojureScript users Transit delivers little new in terms of feature set over EDN but the performance gains are quite significant. transit-cljs is up to 18-20X faster than cljs.reader/read-string on the EDN equivalent. Under V8 JS environments (Chrome, Opera, Node.js) I consistently see transit-cljs outperform JSON.parse on the equivalent data." Ref.: https://news.ycombinator.com/item?id=8081304

why is cljs.reader/read-string so slow then

compared to transit I mean

btw, for me it's not a concern, I haven't really noticed

Because no part of it can be implemented as native code

At least I suspect that's the main reason

@jaen: what do you mean? cljs.reader/read-string and transit-cljs are both running on javascript

(for the browser, I mean)

Yes

But the main encoding for transit is basically a JSON array.

You send it to JSON.parse which is native code, and hence - fast

Also, it's even faster than parsing typical JSON, because it's just a flat (or flat-ish) array, not a nested object literal.

EDN can not use any of this, since no part of it is represented with something JSON-compatible

You have to parse the string char by char in JS

So it'll be slower

@jaen: I was aiming at the edn case: in transit it's said to be faster then cljs.reader/read-string. So then why don't they make that just as fast as transit

Because it's impossible

You would have to force each browser vendor to implement EDN then

Or chuck EDN out and use transit

EDN as-is can't be really much faster in browsers

It being a totally different syntax from JSON limits how fast parsing it can get

Since you have to stay in non-native territory of JS

" but the performance gains are quite significant. transit-cljs is up to 18-20X faster than cljs.reader/read-string on the EDN equivalent." <-

Think of it like this - why C is faster than Ruby?

@borkdude there is also some caching involved. Much more info in the link. ..but I guess EDN will always be the fastest option for Clojure-server to Clojure-server scenarios.

@jaen: what you're saying doesn't make sense to me: in the edn case in the browser, both transit-cljs and read-string perform the same task: turning a string into EDN. This has nothing to do with native code.

Yeah, on JVM there's nothing to limit it's speed and since it's a less rich format than transit then it's quite possible to have it parse faster.

@borkdude: then tell me how is JSON.parse implemented. Inside the browser in C/C++ or in Javascript?

@jaen JSON.parse doesn't have anything to do with parsing a string to EDN

or maybe I'm missing something

Hm, give me a second

Maybe I'm misunderstanding you

ah

Ok

Look

@jaen: Maybe I'm getting what you are aiming at. Transit uses json under the covers as a transport format?

Like I said, JSON.parse has nothing to do with parsing EDN string, but ha everything to do with parsing a transit string. Transit string is, like I said, encoded as a JSON of flat arrays.

Yes

And due to that it can be this fast

@jaen: Then it makes sense. ok

Sorry I wasn't clearer '

no problem