🚀 - Default settings

[riccardoperra]

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

[hackpirodev]

Based on the current code, we can see that all the necessary information for settings is already saved in the Project model. The code snippet below shows how the frame, terminal, editors, and editorOptions settings are being saved:

// from the services allow us to save in indexDB our settings
  const dataToSave: ApiTypes.UpdateProjectApi['request']['body'] = {
            frame,
            terminal,
            editors,
            editorOptions: options,
          };

To solve the problem of separating the SnippetEditorTab[] from the rest of the settings data, one possible solution is to create a new entity, as suggested in the original analysis. However, instead of using a JSON type field to save the configuration data, we can create a new model called Preset with the same structure as Project, but without the SnippetEditorTab[] field:

model Preset {
  id              String               @id @default(uuid())
  name            String
  frame           SnippetFrame         @relation(fields: [frameId], references: [id])
  frameId         String               @unique
  terminal        SnippetTerminal      @relation(fields: [terminalId], references: [id])
  terminalId      String               @unique
  editorOptions   SnippetEditorOptions @relation(fields: [editorOptionsId], references: [id])
  editorOptionsId String               @unique
  createdAt       DateTime             @default(now())
  updatedAt       DateTime             @updatedAt
  owner           User                 @relation(fields: [ownerId], references: [id], onDelete: Cascade)
  ownerId         String

  @@unique([id, ownerId])
  @@index([name, ownerId])
}

Then, we can update the Project model to include a reference to the Preset model for the settings data, like so:

model Project {
  id              String               @id @default(uuid())
  name            String
  editorTabs      SnippetEditorTab[]
  frame           Preset         @relation(fields: [presetId], references: [id])
  presetId         String               @unique
  createdAt       DateTime             @default(now())
  updatedAt       DateTime             @updatedAt
  owner           User                 @relation(fields: [ownerId], references: [id], onDelete: Cascade)
  ownerId         String

  @@unique([id, ownerId])
  @@index([name, ownerId])
}

With this new structure, all references to the settings data should be linked to the Preset model instead of the Project model. This approach has the benefit of keeping the data structured and maintainable, making it easier to make changes or add new data to the settings in the future.

considerations

The original analysis also suggested using a JSON-type field to save the configuration data in the Project model. Still, this approach can lead to inconsistent data in the long term and can be more difficult to maintain and migrate if the structure of the data changes.

Before we start implementing the newly proposed solution, I'd like to get your opinion on it. It seems that the solution will require more effort and specific attention during the migration process, especially since it will impact the core structure of our current schema, and maybe we want to do this. What do you think? @riccardoperra

[riccardoperra]

This solution in my opinion requires more effort and too much attention considering that it's only a "template".

Still, this approach can lead to inconsistent data in the long term and can be more difficult to maintain and migrate if the structure of the data changes.

I'd rather add a new column version in order to know how's the data structured. At this point in the rest api we can add a layer of "data mapping" where we return the Project dto based to the preset version type.

What do you think about this?

EDIT:

Also important, I would never bind a project to a preset. At this point presets would be only a template to import that "reset" the state with the returned options 🤔

[riccardoperra]

For the mapping layer, we are already doing it since there is a module for a prisma types and a mapping of the API. Previously we only did a 1 to 1 mapping, here we can do something more specific.

https://github.com/riccardoperra/codeimage/blob/main/apps/api/src/modules/project/mapper/create-project-mapper.ts

Imagine a different mapper by the version, 0, 1 etc..

[riccardoperra]

Live with 1.4.0