This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
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?
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
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.
@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: 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
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
@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
" but the performance gains are quite significant. transit-cljs is up to 18-20X faster than cljs.reader/read-string on the EDN equivalent." <-
@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
@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.