DEV Community

Discussion on: 60fps with Functional Programming in idle time

Collapse
 
miketalbot profile image
Mike Talbot ⭐

Hey not used it, but looks useful :) Are you letting it parse JSON for you? If you are parsing JSON with it, I'd suggest using it to get plain text and then use parseAsync as this can be very slow - do feel free to create an issue on the GitHub and we can see what's possible.

Collapse
 
vldmrgnn profile image
Vlad • Edited

Thanks. Actually I do some minor data manipulation on arrival (e.g. lodash/fp "keyBy" s.o) then dispatch to Redux Store. I'll check it deeper and if needed I will make an issue on GitHub as you suggested.
Thanks again!

Thread Thread
 
miketalbot profile image
Mike Talbot ⭐ • Edited

Ok that keyBy might be an issue if the data is huge. You/I/we could do a version of keyBy that uses reduceAsync and that would split it up over frames. Fundamentally that would probably look like this:

function keyByAsync(items, predicate) {

    return reduceAsync(items, reducer, {})
    function reducer(acc, cur) {
        acc[predicate(cur)] = cur
        return acc
    }
}

      await keyByAsync(yourArray, v=>v.somethingOrOther)

That's making a single lookup rather than a key to array - but it sounds like this is what you are after. It's a useful function, I may clean it and a few others like groupBy and add them. Basically anything that takes a while benefits from going through one of the async functions which yield every 8 times (by default) to see if there is still time.

Thread Thread
 
vldmrgnn profile image
Vlad

Yes! It has to be this. The keyBy is really needed as the reducer was built that way for O1 access with selector and so on... I will try to put up something here to test but I am pretty sure that your keyByAsync would be much reliable than mine:) So I will stay tuned for update. Thanks a lot!

Thread Thread
 
miketalbot profile image
Mike Talbot ⭐

Totally makes sense to me. Ok I'll sort it over the next few days.