Fork me on GitHub
#reagent
<
2015-09-19
>
gadfly36103:09:03

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 simple_smile

konrad szydlo14:09:28

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

borkdude14:09:17

@konradszydlo: is the db on the server side?

konrad szydlo14:09:06

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

jaen14:09:33

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

jaen14:09:44

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

jaen14:09:05

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

borkdude14:09:27

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

konrad szydlo14:09:29

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

konrad szydlo14:09:43

thanks @borkdude simple_smile

jaen14:09:02

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

borkdude14:09:08

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

borkdude14:09:37

@jaen: right

jaen14:09:21

@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

borkdude14:09:50

@jaen @konradszydlo why not just keep it all edn

jaen14:09:02

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?

borkdude14:09:30

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

jaen14:09:11

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

borkdude14:09:14

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

luposlip14:09:54

@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?

jaen14:09:00

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

luposlip19:09:53

@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

borkdude19:09:25

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

borkdude19:09:58

compared to transit I mean

borkdude19:09:16

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

jaen19:09:22

Because no part of it can be implemented as native code

jaen19:09:41

At least I suspect that's the main reason

borkdude19:09:05

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

jaen19:09:07

(for the browser, I mean)

jaen19:09:35

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

jaen19:09:47

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

jaen19:09:15

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

jaen19:09:39

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

jaen19:09:47

You have to parse the string char by char in JS

jaen19:09:52

So it'll be slower

borkdude20:09:20

@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

jaen20:09:33

Because it's impossible

jaen20:09:57

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

jaen20:09:04

Or chuck EDN out and use transit

jaen20:09:20

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

jaen20:09:34

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

jaen20:09:45

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

borkdude20:09:48

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

jaen20:09:16

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

luposlip20:09:03

@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.

borkdude20:09:05

@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.

jaen20:09:13

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.

jaen20:09:41

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

borkdude20:09:01

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

borkdude20:09:25

or maybe I'm missing something

jaen20:09:43

Hm, give me a second

jaen20:09:48

Maybe I'm misunderstanding you

borkdude20:09:04

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

jaen20:09:06

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.

jaen20:09:21

And due to that it can be this fast

borkdude20:09:28

@jaen: Then it makes sense. ok simple_smile

jaen20:09:42

Sorry I wasn't clearer '