🚀 - Default settings

[hackpirodev]

Discussed in #466

^{Originally posted by riccardoperra February 16, 2023}
Related to #451
cc @hackpirodev

Description

Settings default is a new feature of CodeImage that allows users to save their snippet configuration remotely. This issue can be related also to previous idea of #57, closed during the hackathon due to lack of time and no way to store remotely the data, since CodeImage had not backend at that time.

In the last minor update CodeImage also added the randomize feature which allows you to randomly select a configuration, but then it is difficult to save that configuration and reuse for other snippets.

With Default settings feature, the idea is to have it in the UI, or in the actions of the actionbar a way to save your own themes and select from saved ones.

CodeImage currently could be used from both guest and logged-in users.

In case you are a guest, all of these informations could be saved through indexedDB locally. In the end if you always use the same chrome and pc the settings should not be cleared.

In case the user is logged-in, we could opt for a new "metadata" table for users, to save all the additional information. A drawback of this could be the db usage. The more extensive use of the database costs money, but we don't expect to have that much data. Currently with 700 users, 1000+ projects and so one everything is ok.

Since we are using Auth0, we can try to check if it makes sense to save something at the user metadata level, even if I have read that it is not very recommended. Not having a service like supabase we are a bit limited from the auth side.

So, if we go for the db/api custom way, here's what we may have to do something like this:

• Create a new field "presets" for users. There will be a one-to-many with a new Presets table which will contains an id, the name and the configuration saved as JSON type.

• Create new api's for CRUD:

  • Create preset
  • Delete preset
  • Update preset
  • Search for presets

---

@riccardoperra I'm putting here some points as discussed in telegram:

• add configurable presets limit feat(api): add configurable preset limit #498 @riccardoperra
• to handle presets even in offline mode, if we are not logged we should persist data on indexedDB. If we are logged we should handle using optimistic ui
• fix labels of the dialogue / refactor it creating a separate component @hackpirodev
• to do a "fallback" content like the one already done on the dashboard page for empty items @hackpirodev
• to handle state using StateBuilder, in this case, we lost the possibility of using Suspense with the createResource. Maybe it could be useful to find a way to merge this stuff
• update the already existing preset feat: update preset #502

[hackpirodev]

@riccardoperra I updated the discussion here to have a shared todo. If you want to add something only edit it, I tag myself at the point where I'm working on

[riccardoperra]

I'd say also that we have to add this:

• add preset data field constraint in backend with typebox
• add client side preset limit

Also I'd like to push these with this feature:

• SolidJS upgrade to latest version
• StateBuilder update to 0.4.0 chore: update versions statebuilder#18

Removing also solid-aria for dialogs/dropdown could be also good using snapshot of https://github.com/riccardoperra/codeui

[riccardoperra]

@hackpirodev the last remaining ticket is add client side preset limit

In the backend side we already added a PRESETS_LIMIT config in the .env file on the api module.

We should add a validation also on the frontend side in order to limit the amount of presets for guest users.

Then we have to add two new properties:

• PRESET_GUEST_LIMIT: number | undefined
• PRESET_LIMIT: number | undefined

We should use the right environment value for guest and logged in users. If the users is exceeding the maximum number of presets, the button "Add new" and "Sync" (for logged in users) should be disabled.

[riccardoperra]

To be deployed in 1.4.0