Hi, I'm learning re-frame by building a fairly complex audio application, and am looking for examples for reference/inspiration. I'm not having any particular issues but just curious to see how folks deal with the Web Audio API, and want to learn how to do everything "properly".

So far I have found this: https://github.com/baskeboler/cljs-karaoke-client

Thoughts on how to create a debounced subscription?

@kenny https://gist.github.com/isaksky/2cc3779b52305e992c6150863454a9af

@kenny the UI is only redrawn once every animation frame. subscriptions are calculated at that frequency too. Do you need to debounce more than that?

For example, are you de-bouncing server interactions, in response to user input changes?

Unfortunately, I think so. I have a s/valid? call in a subscription. That subscription is getting updated every time the user types in an input box causing significant lag while typing.

@kenny So perhaps the other way of saying this is: I need to debounce the server requests?

No. It's all local.

The subscription is pulling in a large map and validating it against a spec. The user's input is only changing one small part of the large map.

When the user types in an input, it causes that subscription to run every single time a letter is added/removed.

Reminder: subscription are simply a way to deliver data (a materialized view of data) to views. They are reactive. When the underlying data in app-db changes, data will flow through the subscription. So why is the subscription doing validation?

To enable/disable a button & show an invalid message.

The event handler putting data INTO app-db should be validating.

You'd have the same problem though.

So: 1. each time the user types something in 2. an event is dispatched 3. an event handler updates app-db 4. causing subscriptions to fire?

Correct. Somewhere the "expensive" s/valid? call needs to occur.

IMO, any validation should really be happening in step 3.

As you say, perhaps we are just moving the problem,

Technically the valid? is a projection of the data in the app-db. It seems clean to have it in a subscription.

I think in this case I would debounce the event, and have the input be uncontrolled

or use a local ratom that wasn’t tied to the validation

I disagree.

valid? is about the state in the app

When you update the app-db you are changing that sate

Right, but being valid depends on context.

Hmm. What context?

Other data in app-db?

The view.

Yes

there are two contexts: - UI state - state of application you want the user to be able to put garbage in the UI, and validate it before it populates the application state

It gets complicated to have it in every event handler. We have hundreds of inputs that would all need to be debounced and include the s/valid? call.

No, sorry. Data going into the DB not passing the Spec is ok.

So the key consideration here is that valid? is expensive to compute

And each user imput processed requires that is be recomputed

even still, updating the app-db in this case is expensive because of the validation

you can easily build a debounced-input component that will track its UI state locally and call the on-change handler only once per 300ms or so

from the outside, it’s pure but you get your perf benefits

Indeed

Hmm, interesting.

I know because I just did this :<

So you are debouncing the changes to app-db

But I'd still be thinking carefully about the expensive validation process.

Is there some way to make that less expensive More incremental

Then, this whole problem goers away

^^ slack reordered my messages, have corrected

It's tricky. Probably is the answer but would likely require more engineering time.

There's lots of and type predicates in this validation that requires a larger "scope" to correctly validate.

So it wouldn't be as easy as, say, attaching a Spec to a single :input.

Really the tradeoff is in UX, I suppose. You either provide the user an immediate feedback on valid/invalid or you do it on click.

Not all UIs can do the latter though.

I think it’s generally accepted practice to have complex UIs that track their state locally and then populate up on debounce/blur/etc. for performance or UX reasons.

Hard to know what to do without knowing your application but you could do: 1. Update the app-db straight away 2. signal that you want to do a validation in 300ms time Which is effectively debouncing the expensive valid? check

But updating app-db straight away

problem is that you still need to do the work of debouncing the signal to validate or else you still end up chugging

Dunno if that would work

the use case I had recently was filtering a huge table of complex, calculated data. there had been several attempts to address this with various methods, one of which was firing an event to do the re-calculating <n>ms after updating the db with the filter. this still caused lag, because the CPU from the re-calc events would end up blocking the event queue

the best way we solved it was with the debounced-input component idea above.

1. it’s quite easy to debounce the input using the google closure library, whereas debouncing a dispatch required us to do side-effects directly in our event handler 2. we can now remove all of the logic spread across our event handlers in dealing with this perf problem and instead isolate it to this component that is a drop-in replacement for an :input tag

Interesting ideas. I'm going to go down the path of the debounced-input since we already have an input component and this is really easy to throw in there. Sounds like it'll just work 🙂 Thank you for the help!