Does not play nice with react router / rc-menu about cassette HOT 7 CLOSED

The problem is when you

Each time you navigate it sends in a new prop causing the: componentWillReceiveProps to fire which resets the play list. I am working on a solution. Once I have it I will fork the project and then submit a merge request.

from cassette.

@MichaelLeeHobbs thank you! I'll be happy to look over the PR and merge as long as it makes sense. Sorry for missing your post earlier.

from cassette.

@benwiley4000 I ended up customizing the player. I'm building a podcast website. Originally, I was passing a reference up from the component that holds the player and then back down into any component that would need access to it. This was cumbersome, so I put the player in the global context for now like so and removed the componentWillReceiveProps.

componentWillMount() {
  window.Player = {
    play: this.play.bind(this),
    addToPlayList: this.addToPlayList.bind(this),
    clearPlayList: this.clearPlayList.bind(this)
  };
}

play(value) {
  console.log("AudioPlayer.addToPlayList.value: ", value);
  if (!value.url || !value.displayText) {
    return;
  }
  this.playlist = [value];
  this.currentTrackIndex = -1;
  this.skipToNextTrack(true);
}


addToPlayList(value) {
  console.log("AudioPlayer.addToPlayList.value: ", value);
  if (!value.url || !value.displayText) {
    return;
  }
  this.playlist.push(value);
}

clearPlayList() {
  this.playlist = [];
  //this.togglePause(true);
  this.currentTrackIndex = -1;
  this.setState({
    activeTrackIndex: -1,
    displayedTime: 0
  }, () => {
    this.togglePause(true);
  });
}

from cassette.

@MichaelLeeHobbs alright - for future reference though, I would love a semi-thorough description of what you see to be the problem with the player's current implementation, so that I could make it better.

from cassette.

If you have an example repo demonstrating the problem that would be ideal - perhaps you could direct to an earlier commit where you were experiencing said problem so I could take a look?

from cassette.

I'm re-reading this thread and it makes sense to me now.

The simple solution to your problem is to check for playlist equality (===) in componentWillReceiveProps, and return if so.

This brings up a few other questions though -

1. Currently, if the new playlist prop is falsy, it gets ignored. This seems contrary to React principles, so perhaps that should result in the playlist stopping or fading out?
2. If we agreed on the playlist equality test, does that mean a playlist that is deeply equal but not equal-equal should reset the player? For example, what if your application triggers a new playlist async fetch and at the end the Redux builds a new copy of the same playlist? Should the default behavior be to reset?
3. Further, if we decide NO it should not reset, how about a playlist which is different but contains the song which is already playing? I wonder if we should preserve playback but change the index of the currently playing song to match its index in the new playlist.

Perhaps some config options should be available to change this behavior but I am leaning toward allowing continuous playback for new playlists as long as the current track is still in it.

from cassette.

I decided to go ahead and make the changes I described. The original issue should be resolved, and the player should work better in general when swapping playlists. See #10.

from cassette.