Persist UI settings in database

[avee87]

Exploring implementation for #31 For now just for UI settings such as dark mode and lowercasing things.

Settings are keyed on app token but I also hash it to prevent storing it in database as is.

[cioraneanu]

Some observations:

• hash the token on the backend. You dont want the client to be in charge of this
• dont create separate columns for each setting. This creates a lot of unnecesary boilerplating + maintenance. Ex. deciding to rename a property on the frontend requires backend migrations, fillable change etc... My suggestion create a single table called tokens / profiles and with a jsonb column like settings/preferences which will hold all user key/value pairs.
• we don't want to ever redeclare any of the persisted settings(not even in the getEmpty()). Need to hold a single source of truth
• dont add the unnceseary .ui path to the pinia store
• for the last problem mentioned above just use some JS:

      // Before
      this.ui.darkTheme = newValues.darkTheme
      this.ui.numberFormat = newValues.numberFormat

      // After
      for (let key as Object.keys(newValues)) {
           this.ui[key] = newValues[key]
      }

[cioraneanu]

Nice! Already looks way better. A few more observations:

• as per laravel recomandations the resource names should be in singular form. Instead of "AppSettingsController" use something like "ProfileController" ( + associated resources )
  • AppSettingsTransformer.js should send and receive the settings as objects not strings. It's the backend's job to encode to whatever desired format
  • the new endpoints should be REST like: GET /api/profiles/<hash>
  • RouteConstants.ROUTE_APP_SETTINGS is unused
  • front/models/AppSettings.js class name left UISettings

[avee87]

the new endpoints should be REST like: GET /api/profiles/\

It’s not hash, it’s full access token which is insanely long. I’m not sure it’s a good idea to pass it as part of the path.

[cioraneanu]

Indeed. Then I guess we can just remove it, have the route as GET /api/profiles and read the token from the Authorization header.

Also in the new DB migration let's create a primary key "id" to future proof it. This way we can later turn it into a classic REST approach (ex. Let the user manage multiple profile settings)

[cioraneanu]

Awesome contribution! 🚀 ❤️