search

bellingcat / avoc

Working repo for the 2024 Bellingcat Tech Fellowship.
GNU General Public License v3.0
49 stars 7 forks source link

Add a configuration window on the UI #2

Open haruspeks opened 4 months ago

haruspeks commented 4 months ago

The configuration module already supports read and write from sessionStorage and localStorage. A dialog modal could be added on the frontend to let users configure Avoc directly on the UI instead of relying solely on the configuration.js file.

roberrrt-s commented 4 months ago

https://caniuse.com/?search=dialog

Will impact the browser versions, but probably the best option. Let me know if you're okay with it and I'll shoot in a PR

haruspeks commented 3 months ago

Dialogs have been implemented already for the weather and shortcuts modal, so no problem in using them.

If you want to have a go at it, be my guest!

Although the architecture should be fairly straightforward, I'll just leave a couple of notes:

  1. dialog open/close toggle is handled by Alpine using the x-ref directive leveraging Pico's modal component: $refs.nameoftheModal.addAttribute('open') and $refs.nameoftheModal.removeAttribute('open')
  2. the Configuration class already reads both session/local storage and the configuration.js, so it should only be a matter of adding a set method, and then expose the object to Alpine by adding a store on the alpine:init listener
  3. self.configuration.language is just a ISO 639 alpha-2 string at the moment, I will prepare a PR to add a static list of supported languages
  4. as per self.configuration.screens, handling the compatibility between provider and type might be a bit of a brainy exercise; I'm open to any idea on how to handle that
haruspeks commented 3 months ago

New method that exposes supported languages has been added, see PR#3

GalenReich commented 2 months ago

Late to the party, but want to definitely +1 this issue.

Some suggestions on the different layers of configuration. There could be a top level configuration of number of screens and their respective types. Then each screen could be populated with a drop-down allowing users to switch between supported types for which an API key exists.

If you are still interested @roberrrt-s, I can formally assign you!

roberrrt-s commented 2 months ago

Late to the party, but want to definitely +1 this issue.

Some suggestions on the different layers of configuration. There could be a top level configuration of number of screens and their respective types. Then each screen could be populated with a drop-down allowing users to switch between supported types for which an API key exists.

If you are still interested @roberrrt-s, I can formally assign you!

Sounds like a plan, I'll schedule some work to do in a week (10th of Sept) since I'm covered in deadlines until then.