Ahhh ahh okay. That makes sense.

Nope, actually that wasn’t the problem, you can run the handler on figwheel, the problem is that I had the uri wrong. I should have had "/api/v1" instead of "/api/v1"

I'm struggling a bit with a long initial load time and I'm hoping someone can point me to the right place in the docs for managing this... in my [:initialize-db] I'm kicking off an xhr effect to pull down a 60,000 line CSV file with all my data. The parse (in my xhr success handler) seems to take about 5-6 sec and blocks the event loop.

what's the usual way to get that as off the single thread as one can in JS? ... I gave core.async a go but it's quite probable I'm not using it right.

Try co-effects, @rgm, using tips from PurelyFuctional https://purelyfunctional.tv/guide/re-frame-building-blocks/#co-effects

@rgm https://github.com/Day8/re-frame/wiki/Solve-the-CPU-hog-problem

You can also look at running a web worker to do the processing. I don't think that is a very well trodden path in ClojureScript though, and getting the data back over the serialisation boundary might be tricky

Thanks @lovuikeng @danielcompton

@rgm also you could take a look at storing the data as JSON or transit, as they are probably faster to deserialise

So it seems like a batching approach is called for in the CPU hog article.

Oh good point

I’m not quite grokking how spinning off a coeffect would avoid locking up CPU.

Thousands of hours have gone into browser's parsing JSON fast

I don't think coeffects would avoid CPU lock, but it would be more idiomatic to do the parsing work in an effect handler, rather than in the xhr success callback

I have full control over the data; JSON/transit will be the biggest gain at least complexity <smacks own forehead>.

But yeah, I guess next is to push off the parse as a coeffect and after that deal with chunking it up.

Thanks again.

no problem, also Transit lets you parse a stream of values, whereas standard JSON needs to read the whole object in one go

So you could chunk Transit it on the server side, and parse a chunk at a time

sorry, @rgm, thought you'd like to do something else while processing the bulk 😞

No worries. Appreciate the pointer.

you might want to go crazy with cljsjs/oboe for JON Streaming http://oboejs.com/

Whoa.

not sue if there is clojure backend to spit out the streaming though

got the idea from Spring WebFlux

Also generally the re-frame docs are amazing and I want to thank @mikethompson @danielcompton and everyone else involved a whole ton.

you don't say, @rgm re-frame makes Web development fun again 🙂

Dang, the 7-8 sec CSV parse is now < 1s using JSON Transit.

gzipped size of the CSV and Transit are both around 350kb.

And of course being Clojure pipeline-y code there was only one function to rewrite in the spreadsheet "juicer" that I made to produce the data files from a giant Excel hairball of engineering data.

honestly the best part of being just past the steepest part of the Clojure learning curve is that I learn about something new (eg. Transit), start using it and it's just like Christmas happening about every 36 hours.

@lovuikeng completely, utterly agree... I have one client project I've been working on since 2014 for which they chose Meteor and this is better in just so many ways. The despair is gone.

it'd be even more fun if re-template include profiles of duct (for backend) and semantic-ui-react (for UI) 🙂

@lovuikeng just to close the thought on the parser, am I understanding right that the more correct approach on a parse would be to stick it into the :after of an interceptor? It seems to be related to coeffects but I was having trouble grokking how a parse (being in response to receiving data) would fit into coeffects, which seem to be a before kind of thing.

And now I see that coeffects seem to be :before interceptors, which is slick.

I guess the alternative is to register a parse effect and put that in the effect map.

Maybe that’s less magical.

@kennethkalmer brings up tips on "Layer 3 computations", might something to look into https://opensourcery.co.za/2017/02/12/using-semantic-ui-react-with-re-frame/

@lovuikeng @kennethkalmer I’d also check out Soda-Ash which is a wrapper around semantic-ui-react so you basically get all the Reagent components of semantic-ui-react for free. https://github.com/gadfly361/soda-ash

and if you want to go further down the rabbit hole there is sodium which is a wrapper around soda-ash to provide validations and useful re-frame functions 😝 https://github.com/deg/sodium

I have used soda-ash personally quite extensively but have never used sodium

funny enough, the reworked soda-ash version came out within hours of that blog post, total coincidence

or the other way around, can’t remember exactly

thanks for the tip on sodium though, forms & re-frame & myself aren’t the best of friends yet

Yes, I've checked out both too, @kasuko Only that I'm still trying to get around re-frame, and @kennethkalmer tips is simply great for working with react components like the fantastic semantic-ui 🙂 And I tend to like a simple wrapper which still stick to re-frame subs/dispatch API

soda-ash works great with re-frame subs/dispatch. You just don’t have to write that component wrapper yourself

Good work, @kennethkalmer 👍