Refactoring nowPlayingPage (playback/queue) and converting it to React

[dkacperski97]

I want to start working on refactoring nowPlayingPage and converting it to React, but first I want to know if my plan for it is okay.

Because nowPlayingPage is one of the legacy pages with complex logic, I think the best solution to eventually convert nowPlayingPage to React is to first split the page into smaller components. The logic of for example: btnPlayPause, positionSlider, volumecontrol can be easily moved to separate components. After splitting, such components could be converted to React. Code review of smaller parts would be easier, and it would be also easier to maintain the stable and experimental version of these components if changes had to be made. It's probably not possible to separate everything nicely, but it would be a good start. Perhaps some of the separated components could also be used by nowPlayingBar.

If we don't want to use any type in React components for some of the variables, types would need to be added to the playbackmanager. It is over 4000 lines long, so it would be easier to add types only to the functions used by nowPlayingPage. Or would only the full typed manager be accepted in Jellyfin repo?

The playlist on nowPlayingPage has drag&drop functionality. Could the React version of playlist component use some npm package to handle it?

[dkacperski97]

I created a small proof of concept of splitting nowPlayingPage logic: https://github.com/dkacperski97/jellyfin-web/pull/1/files

At first I copied all the logic related to btnPlayPause to a new component (dkacperski97@25b5b0d), but I think the task of watching playerchange, statechange, playbackstart and playbackstop events should be done by parent controller. So I removed this part from btnPlayPause and now remotecontrol after this events are triggered just calls onPlaybackStopped, onStateChanged or onPlayerChange in btnPlayPause. (dkacperski97@7fea3d3). The pause and unpause events only have impact on btnPlayPause, so I left them in btnPlayPause. The pause and unpause events have also impact on playlistIndexIndicatorImage, so they also should be watched in parent component - I will have to fix that in my PoC (or maybe because they impact only two components, these events should be watched separately in these components).

It could be similarly done in React. The value of currentPlayer and state would be passed in props to children components and when the value of them changes after the playerchange, statechange, playbackstart and playbackstop events are triggered, appropriate functions would be executed in children components by useEffect hook.

Let me know what you think.

[thornbill]

I really should write some of this down somewhere...

• Breaking down these giant files into smaller pieces is definitely a welcome improvement. (I recently did this for the home screen sections.)
• New files should preferably be written in TypeScript.
• Any API requests should be updated to use the TypeScript SDK when possible.

Currently migrating things to React can take 2 different paths:

1. Perform a 1:1 conversion using React wrappers for the "emby components".
2. Write a new version in the "experimental" app/layout using the new "architecture".
   • MUI components
   • TypeScript
   • React Query + TypeScript SDK for API requests

Currently the experimental layout must be enabled manually under display > layout, but it should become the default in the future (except when the TV layout is used). The experimental layout will also be the target for future redesign efforts.

[beakerandjake]

I'm 100% behind getting this stuff formally documented, I think it would really help getting new contributors up to speed. A few things I think would be really helpful to see on the README (or somewhere similar):

1. A section providing a little context and history of the current codebase and migration efforts. Details like: what was the original project written in, where does the majority of the old / new code live, when was the migration started, etc.
2. Steps for developers migrating features. Your details in this post were super helpful.
3. Preferred place where development efforts should be focused, should I as a new contributor be focused on trying to fix / add new features to legacy components in the "stable" section, or should I be doing the work in the new "experimental" section.

I can open a new issue if we want to track / discuss this too.

[thornbill]

👍 yeah let's continue this in an issue.

[beakerandjake]

Sounds good I'll open one 😄

[malykhinvi]

For those who follow this thread: this is the ticket - #5182