Fork me on GitHub

Hello, guys! I was wondering — suppose I want to storage in my default-db json like ~500k rows Is that huge? Which limits I should follow? And another approach — if I have a large data on client — datascript is a good choice? That library allows use re-frame model and datascript for storing — anyone try it?


DataScript is not a good choice is you have a lot of data. Things will become very laggy and transacting that much data is very difficult to do without pausing the whole UI.


i like datascript for prototyping, but some queries need caching or if everything becomes slow, you need to rethink the datastorage completely. usually u can just take all entities from datasript and somehow manage them manually in a normalized app-db


when accessing data from an event handler, which is more idiomatic/appropriate - to access in the db directly or use @(subscribe <subscription>) - or some thing else...


Hello! I have a rather newbieish question: I have a long table that is generated from a vector of maps that I map over. Since it's so long, I'd like to repeat the headers every maybe 30 lines. The best idea I had would be an atom to count the lines and then insert the header, but maybe is a better way?


have a look at partition ^ @igel


mccraigmccraig: Thanks, looks nice!


@danieleneal You mean inside the event handler itself? Definitely just access db, thats why there as an argument :)


Is it possible to cancel a dispatched event in an interceptor? I tried clearing the :queue but received an error

Error: ["unrecognized response format: " nil]


I could just let the event run and just update the context :after but the event has to do some heavy calculations that I'd like to avoid if possible.


@danieleneal I'm still pretty new, but I don't think you can even use subscriptions in event handlers without getting errors ( So stick with the db that the event provides. If you want to reuse code that is in the subscription then just define a function which can be used in both the subscription and event.


@danieleneal it's definitely best practice to access the db directly in event handlers. I usually have separate functions for each subscription so I can use those functions in the db if necessary.


What's the right way to model effect-chains? e.g. I need to issue XHR requests to three servers, each request containing the result of the previous response.


Have your XHR handlers be the next XHR in the chain. If you're looking at the example on ( then have your :process-response be another XHR


So I'd have uniquely named :process-responses for each step in the chain?


What if some of the steps can happen in parallel?


e.g. XHR for data (a) and (b), and use (a) and (b) in a request to get (c).


Seems like I'd want a custom reg-fx to handle the split/join?


>So I'd have uniquely named :process-responses for each step in the chain?


You don't have to, but probably should to make it more readable


@zane: you might also want to check out which basically gives you a mini state-machine DSL for doing these kinds of things


If A and B can be run in parallel have the initial event dispatch both events using :dispatch-n. When request comes back check if the other request has been done too (you'll want to save the responses in your app-db). When both are done dispatch C. I hope this is clear.


That is clear, thanks!


@timgilbert Nice! Would you say that library has wide adoption?


This all seems much more verbose than just handling the effects with core.async as one normally would.


But I suppose that's the price you pay for debugability, undo/redo, etc.


Not sure about the adoption. I found it pretty verbose at first too but I like that all the code is centralized in one place, versus scattered around in various event handlers