Refactor to use track-started and track-stopped

[kimberleehowley]

ETA: This is now ready for review (see comments below).

[kimberleehowley]

Hi, @jessmitch42!

@philmillman mentioned that you might have some time tomorrow to revisit our original React demo refactoring. I hope this tag is okay!

There are two main things I am struggling with: 

1. The shared screen for the person screensharing is backwards
2. When I stop a screenshare, the black tile remains. Because, I think, when a participant stops sharing their screen, 'participant-updated' fires along with the 'track-stopped'. Then addOrUpdate() participant runs with empty track state being passed to the tile. 

I've tried, among other things: 

• Checking the state of the track within addOrUpdate(), but I must be doing something wrong. 
• Exiting out of handleParticipantUpdate under various conditions, to not much luck (aside from my workaround to make sure the shared screen displays). 
• Changing the id of the tile to the track id, but that was a bust. Instead, I now look at videoTrackState now to remove the tile.

If you have any ideas for managing the event bubbling (I was looking up stopPropagation for custom events), I'd appreciate it.

And/or, if there's another direction to solve, or if there's a better way to approach from scratch (I'm currently storing a lot of screensharing state), I'm all ears.

Thank you so much!
Kimberlee 

[kimberleehowley]

Hi, @jessmitch42 and @kompfner!

At long last, we've got a refactored version of the OG React demo that 1) Relies on track-started and track-stopped to add tracks and 2) No longer needs callState.js or the getCallItems pattern. Jess, thank you again for all of your help!

For this intro demo that doesn't have toooo complicated of a state, I think this setup could be easier to follow for devs newer to Daily and newer devs in general (at least, it was for me). It closely mirrors our party-line pattern.

I successfully tested:

• 2 participants, one leaving in the middle of the call
• Screenshare starting and stopping multiple times for 2x participants
• 3 participants
• Starting a screenshare with 3 participants
• Adding a fourth participant, then a fifth
• Making sure participants could come and go with an ongoing screenshare
• Checking for correct behavior when participant screensharing leaves

When you have 20 minutes some time next week, I'd appreciate your feedback on:

1. Is there anything else I should've tested for?
2. What do you think of this refactoring in general?

Thank you!
Kimberlee