Closed danielr18 closed 5 years ago
I did do this on purpose because I wasn't convinced that "choosing a new track and staying paused" is a popular pattern in media player UI. If we have a good use case we could add the option. Do you have one?
I ended up doing things different to solve what I wanted to do, so I don't have a good use case.
What did you want to do?
I was adding a track at the beginning of the playlist, without playing it, and wanted to make that the active one instead of the current one, since the index is recalculated when playlist changes.
Hm... I'm trying to reserve context actions for things that would be user-initiated if you get what I'm saying. But maybe your issue is a problem we could try to solve. What was your solution?
I ended up removing the current track, not really as a solution to the issue, but because that's how it's expected to be, so I ended up not having the issue at all.
And if you call selectTrackIndex
by an user initiated action, it will mostly be to play it, so I understand your position.
Yeah, I mostly only want to provide options that satisfy real world interaction scenarios because 1. I don't want to have to test more options than necessary and 2. I prefer to guide folks towards UIs that make sense.
Glad you solved your issue! As always, if you think there's something that can be solved better at the library level let me know. :)
selectTrackIndex ends up calling
getGoToTrackState
, which by default hasshouldPlay
arg as true, so you can't change the active track index without immediately playing. Are you open to having an extra param to specify the behaviour wanted inselectTrackIndex
?