-
-
Notifications
You must be signed in to change notification settings - Fork 811
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
Consolidate frontend & backend configs #30
Comments
After clarifying with @gabek how this would work, I think it currently makes sense to put this all the info into one file. I like the idea of having set restricted types of these fields which would allow us to have a more consistent and controllable look and feel across Owncast instances. And in this case, if we ever need to add a new configurable frontend field, all instances would need to be updated to use it because the config structure has changed and the frontend markup will have most likely changed. |
..On that note, can I make a request to add a couple fields to the config? 😁
(Sorry I can't think of a better name for that right now) |
On it! |
@graywolf336 Heads up, this is changed in master, so now both frontend and backend has a single config location. |
Awesome!! 🎉 |
@gabek One more request, regarding the social list in the config- This will let users order their social acts by priority. |
Ok, it now looks like this:
|
* 📝 add initial version of blogpost for 0.0.5 * Update owncast-0.0.5.md * Update dynamic content * Add digitalocean spaces documentation (owncast#30) * Fix link * Update release notes * Add 0.0.5 api docs * Point to 0.0.5 link * Add more changelog items * Point installer at 0.0.5 Co-authored-by: Owncast <owncast@owncast.online> Co-authored-by: Aaron Ogle <geekgonecrazy@users.noreply.github.com> Co-authored-by: Gabe Kangas <gabek@real-ity.com>
I think it would be nice to have a single place to make changes and not have to specify that you're talking about the backend config vs. the frontend config, especially in initial setup and in documentation.
Since we're already pulling in
config.json
on the frontend asynchronously we could simply create a/config
endpoint that returns the same valuesconfig.json
does based on the values inconfig.yaml
and point there instead.No rush to do this, since having a standalone frontend config right now allows faster iteration on the web UI, but would this be a positive change eventually? What are your thoughts @gingervitis ?
The text was updated successfully, but these errors were encountered: