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

@myguidingstar ^^

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.

indeed

nicely said

great. Thanks

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) https://github.com/Day8/re-frame/blob/master/docs/Performance-Problems.md 2) https://github.com/Day8/re-frame/blob/master/docs/SubscriptionsCleanup.md 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.

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

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

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 https://gist.github.com/llsouder/971f21f8a5aea4bfd114f017a9418a2b

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

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

https://reactjs.org/docs/lists-and-keys.html#keys 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 😃

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

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