Fork me on GitHub

I have a cofx handler that must produce data from an async operation (a js promise). How do I do that?


I'd use the same approach as re-frame-http


hmm, re-frame-http is fx a handler, I want a cofx


Oh right. Sorry. cofx can't be async


events have to be handled, right there and then. There's no pausing, waiting.


In practice this is never a problem, but you might need to think about your problem in a slightly different way


I found this clarifying (from re-frame docs) > coeffects is the current state of the world, as data If there was something async going on, it wouldn’t be about “current state” but some uncertain future state of the World. 🙂 That would make it more difficult to reason about. It’s simpler if events are the (only?) source for side-effects.


is there anything special I need to do to reload a subscription via the repl? I’m trying out a new workflow without figwheel reloading but just reloading code in the repl or is this generally a bad idea? I noticed that code changes in event handlers are picked up, but not in subscriptions.


ah, I see, I need to call (re-frame.subs/clear-subscription-cache!)


Hey, any good resources that anyone can point me to that breaks down improving performance in re-frame?


I’ve gone over the usual suspects 😃 -> 1) 2) Some of it’s still a bit overwhelming, if anyone can point at more things that I can look at it would be really helpful =)… I’m pretty sure there’s more I can do.

Braden Shepherdson15:11:13

@folcon I'm not aware of any other documents, but maybe describe your problems here and see if anyone here has tips?


Ok, so I’ve written a fair sized app, and it’s pulling in a lot of external data, so working out at a high level what areas slow-downs are coming from so I can investigate further would be useful.


I’m using the 10x, but it’s surprisingly hard to find issues unless I load in a lot of data, and then doing any kind of careful exploration is really problematic…


Just wondering if anyone has had some good pointers of things to try?

Braden Shepherdson16:11:00

what's bad about your performance? slow view updates, memory use, CPU spinning?

👍 4

If my [:input {:type :text... has a value that is subscribed to and and :on-change that updates that value: Did I just create a an infinite loop? It seems to work but I am not comfortable with this code. Here is a gist with a sample


It’s fine.


There’s no loop. It just keeps the state consistent between app-db and the input. This is very common in React world.

✔️ 4

Is the reason there is "no loop" because the on-change dispatch value is the value in the text box so the subscribe doesn't trigger a render? Or does the text box stop a loop condition because the subscribe sets the value but then on-change is "not a change" so "no loop"?


When you type a in the input, it goes to app-db and subscription reads it from there and sets components value to a and it settles there.


In this case app-db contains the ‘truth’ about components state and not the input itself. In React world these are called “controlled components”

👍 4

thank you, your explanation and the link answered a lot of my question, present and future. 😄

👍 4

@braden.shepherdson Slow view updates and memory use are two big ones, I’ve done some fixes on cpu spinning by chunking work. A lot of react missing keys issues I’ve “fixed” by doing ->

(into [:div] (for [item @subscription] [:div ...]))
(Not that I’m certain it’s a good idea, but it worked.)


One thing that’s currently on my list is working out a good way of batching up datascript transact’s.


But I think that won’t be too big an issue :)…


@folcon that doesn’t fix missing keys issue in terms of perf. React keys exists for more efficient diff’ing


So if you just don’t do them, you don’t get the perf improvement. I’d prefer the into like you have when there is no need for this perf boost


But if it is a large list of dynamically changing items, keys may become important


But they must be identifying keys. Not just positions in the sequence when things are changing the sequence in arbitrary positions later


So a static sort of list that isn’t going to benefit from this (doesn’t really change much across renders and/or is not very big), into is fine. I have no idea your situations though.


It does assign a vector index value to the dom object right? I’m pulling a large number of items out of datomic, so I should be able to use :db/id, but I’m concerned about values with the same key in different parts of the dom…


The vector index doesn’t help though if indices change


The react key identifier is only a local identifier for that particular children component array


You are concerned about global uniqueness?


It’s not a DOM element ID


Ok, so just needs to be unique at the given level in the dom tree? I should probably swap to using db/id everywhere then.


Thanks =)…


Yeah. Should be safe


For a react key

mikerod17:11:20 The couple paragraphs here explain it pretty well. But a key is only useful in the context of the surrounding sibling components.


Ok, that makes sense.


Are there any gotcha’s with regards to memory?


The app I’ve written is pretty heavyweight and I’m really trying to see if there’s any obvious other things I’ve missed 😃

Braden Shepherdson18:11:29

one step would just be to estimate the total size of your Datascript blob.

Braden Shepherdson18:11:42

sometimes you're using your memory to store actual data, and not just overhead 😄


Valid point :)… It’s somewhat dependant on the user, but I’ve seen users query for 5 to 50mb blobs