You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have this idea quite some time now and want to start some discussions around it.
Currently, we use short route prefixes for pages used in OTT:
/m/:id/:slug -> media /p/:id/:slug -> playlist
This is fine, but can be improved for the following reasons:
Search engines can't use m or p to give better context to users
Screen mapping uses different pages and layouts, but all share the same loading screen
Especially the last one is interesting. If we could (optimistically) determine the content type by using custom prefixes for each, we're able to create custom loading screens. Another benefit is that in our apps we have created a stack router. Pressing the back button removes the top-most screen. But because the Hub page is basically a media page, it is replaced when navigating to a media page. This results in skipping the hub screen when pressing the back button.
I have a few solutions, which the most easiest would be to update the AppRouter directly without screen mapping. We keep the /m and /p routes, but redirect to the correct content type screen based on the fetched media/playlist.
The second one is to add a 'route' prefix param to the screen mapping configuration. This will then be used to auto generate routes in the AppRouter.
/movie/:id/:slug -> default movie page /concert/:id/:slug -> concert content type /hub/:id/:slug -> hub content type
I have this idea quite some time now and want to start some discussions around it.
Currently, we use short route prefixes for pages used in OTT:
/m/:id/:slug
-> media/p/:id/:slug
-> playlistThis is fine, but can be improved for the following reasons:
m
orp
to give better context to usersEspecially the last one is interesting. If we could (optimistically) determine the content type by using custom prefixes for each, we're able to create custom loading screens. Another benefit is that in our apps we have created a stack router. Pressing the back button removes the top-most screen. But because the Hub page is basically a media page, it is replaced when navigating to a media page. This results in skipping the hub screen when pressing the back button.
I have a few solutions, which the most easiest would be to update the AppRouter directly without screen mapping. We keep the
/m
and/p
routes, but redirect to the correct content type screen based on the fetched media/playlist.The second one is to add a 'route' prefix param to the screen mapping configuration. This will then be used to auto generate routes in the AppRouter.
/movie/:id/:slug
-> default movie page/concert/:id/:slug
-> concert content type/hub/:id/:slug
-> hub content typeThe text was updated successfully, but these errors were encountered: