Should we update the entire imported react-pro-metronome library to typescript?

[dcallus]

The original library doesn't look like it's going to be updated and even if it were, we need to have it modified for various issues.

We will be adding options for additional sounds, amongst other things, so it might be good to clean it up before we go any further.

I propose that we better integrate this part of the app, by
a) converting it to typescript.
b) not having it imported like a library, i.e. no source folder etc. This way we can move the tests out into the route src folder and get them up and running again.

I definitely think we should leave it state based though. It works perfectly and I don't see the need to convert to functional react. It may not be worth the effort. It may help keep things consistent if we do, but may be easier to add patches if the original library changes. It's kind of nice having it quite isolated and separate as it works so well, but inevitably it will become more integrated over time. I probably need some better folder structuring moving forward.

I'm particularly interested in your opinion chrisd1999 as you've worked a little in this part of the app.

[kristersd]

@dcallus I think, we should create an separate type-safe functional component ourselves, and link the original authors. As there is only one component, which manages the logic, we could split the functionality to be more robust. I can work on this particular implementation, if that may be hard to others. This way we can test it thoroughly, and not rely on their class component implementation.

[dcallus]

Yeah. So unfortunately I've found some stability issues that have been introduced. If you play the metronome and go between quarter note and eight notes for example there is a slight lag before it updates. The previous implementation you could flick between any subdivision as often as you like (whilst it's playing) and it would remain perfectly in time. Also I went back and checked previous implementation and it seems pretty stable when changing tabs etc and just sounds overall more stable. Perhaps related to what I've mentioned above, but I'm not sure.

[kristersd]

@dcallus Ok, gonna check it out. It may be related when the useEffect clean up function run. Thanks for feedback.

[dcallus]

Somehow didn't see this message.. Nice one.. Thanks for looking into it. :) Let me know how it goes.

[kristersd]

@dcallus I have not got the time to check this issue out, hopefully I can manage to do it this weekend. 😬

[dcallus]

No worries @chrisd1999 - Your help is always appreciated. Whenever you can, this isn't an urgent feature but it's definitely a nice to have and will definitely help moving forward. We can progress fine for now though in other areas :)

Also if it's possible before starting, would you be able to tell me if you think that Howler is used (in the original pro-metronome code or your own) at all for stability? For me it looks like it only is used to play the audio.

If it doesn't factor in stability could you perhaps look into the post I mentioned above (https://blog.paul.cx/post/metronome/) and see if it's possible to implement the recommended WebAudioAPI into the metronome's core? along with any appropriate cacheing etc mentioned in the article, or even better, see if Howler can abstract this work as it implements WebAudioAPI.

Thanks again

[dcallus]

Apparently useMemo is a fair amount slower than useState, especially on initial render, which may hint at why it is slow when changing.

I've not had any issues with the rest of the app slowing down to be honest, so could be safe just to use useState as to be honest, the metronome must take priority over all else. I'll attempt to change it and see if it works.

Note 100% if this is relevant, but thought it was worth noting:
https://canimerge.com/should-you-really-use-usememo-in-react-lets-find-out/

edit: nope. that wasn't the issue.