-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove the requirement for a browser to be pointed to the web app in order for the playlist to work #25
Comments
Hi @JonathanDCohen, I won't have a chance to convert this to server side state myself, but I'd be happy to put up a bounty of a free Pixelblaze for anyone that contributes a PR with it. |
I know you mentioned Thoughts? EDIT: I'll peek at socket and see what can be done; looking at socket.io its mostly aimed at chat stuffs... I'm still partial for file storage because it can persist between restarts 🤔 another edit: I think a localdb of some sort might be best here, exploring lite options... another another edit: tinkering with |
I've never used react-native-local-mongodb; since this isn't a native app I wonder if the maintained fork of NeDB is another option. Or SQLite (great project stability/longevity) or a local JSON file sound reasonable. |
Yeah, 💯 I will reach for SQLite, as it seems like a rational choice here and could persist between restarts. I want to keep the implementation as close to an industry standard as possible and light on the machine it is running in. The JSON file will be on the back burner as a last resort. I wasn't aware of NeDB, and I'll also look into that. Thanks! EDIT: okay, |
🎁 💝 #44 This is a working solution. I'll come back and clean it up a little later <3 Be well all EDIT: I added some cleanups, it could use some polishing still, maybe, but I'll yield here for now :P Cheers 🍻 Okay, it's good to go. I've had it running on my local server for 24+ hours, and it works well! |
Currently the playlist state is stored in the React component for the front-end UI. This means that, if you have a field installation of Pixelblazes with Firestorm which you'd like to have shuffle through a playlist, you need a browser somewhere pointed at the Firestorm UI. I've fixed this in my installation by pointing the built-in Chromium browser on my RPi to
localhost
, but it's not a great solution. This also means that if there are two different browsers pointed at the Firestorm UI, they'll compete with each other.This feels like a layering violation to me. The playlist state should live in the API server and be manipulated with the REST API. This way no browser-looking-at-localhost hack is needed and multiple people can control Firestorm at the same time without conflicting with each other.
The text was updated successfully, but these errors were encountered: