|
loadReplay: function(recName, shirts) { |
The loadReplay function does already have a parameter for shirts. However, while looking at a way to implement shirts to elmadev/web, it's occurred to me that the path of least resistance might be to put the shirt in the replay URL as a query parameter. So i've written some code for recplayer-react so that when it calls controller.loadReplay, it will parse the shirt from the URL and pass it as the second argument. But now i'm wondering if it might make more sense to just include this logic inside of recplayer instead, so it's available everywhere.
So instead of passing a URL like: https://space.elma.online/replays/1qdh0g89a8/porco969BZ1994.rec
We could add the shirt: https://space.elma.online/replays/1qdh0g89a8/porco969BZ1994.rec?shirt=https://api.elma.online/dl/shirt/15307 (obviously we'd have to encode the shirt URL here)
(then this repo can be updated to parse the shirt data)
I think using this approach would be compatible with any existing back-ends which serve the replay data. If it's an issue, we could detect if recName is a url, and if it contains a shirt parameter, and if so remove it. Just in case adding query parameters would break any URLs that otherwise serve replay files.
My main question then is whether it seems good to update recplayer with the above. If not I could update recplayer-react instead.
recplayer/src/controller.js
Line 202 in fb9569d
The loadReplay function does already have a parameter for shirts. However, while looking at a way to implement shirts to elmadev/web, it's occurred to me that the path of least resistance might be to put the shirt in the replay URL as a query parameter. So i've written some code for recplayer-react so that when it calls controller.loadReplay, it will parse the shirt from the URL and pass it as the second argument. But now i'm wondering if it might make more sense to just include this logic inside of recplayer instead, so it's available everywhere.
So instead of passing a URL like: https://space.elma.online/replays/1qdh0g89a8/porco969BZ1994.rec
We could add the shirt: https://space.elma.online/replays/1qdh0g89a8/porco969BZ1994.rec?shirt=https://api.elma.online/dl/shirt/15307 (obviously we'd have to encode the shirt URL here)
(then this repo can be updated to parse the shirt data)
I think using this approach would be compatible with any existing back-ends which serve the replay data. If it's an issue, we could detect if recName is a url, and if it contains a shirt parameter, and if so remove it. Just in case adding query parameters would break any URLs that otherwise serve replay files.
My main question then is whether it seems good to update recplayer with the above. If not I could update recplayer-react instead.