I can save field-level settings to DB (size, visibility, ordering)

[FelixMalfait]

Table: ViewFields

Field	Type	Description
id	INTEGER	Unique identifier
workspace_id	STRING	FK to Workspace table
user_id	STRING	FK to Users table settings are workspace-level
view_id	STRING	FK to Views table views are not ready yet
object_name	STRING	Name of the object
field_name	STRING	Name of the field within the object
is_visible	BOOLEAN	Whether the field is visible to the user or not
size_in_px	INTEGER	Size of the field in list view
index	INTEGER	Used to re-arrange column order

For now object_name = Company / Person (plural? lowercase?). In the futur can also be custom object names so probably no need to do an enum

Example usage:
When table view is loading, to know how to display the table

query {
  getViewFields(workspace_id: 1, object_name: "company", view_id: null) { // null = default view or no view implemented
    id
    field_name
    is_visible
    size_in_px
    index
  }
}

When a view is saved we would likely call views endpoint, and pass viewFields through that

mutation {
  updateView(id: null, viewFields: [{is_visible: false}, {...} ]) {
    id
    viewFields
  }
}

If view doesn't exist when this ticket is implemented maybe call viewFields mutation directly?

[Bonapara]

@FelixMalfait I might be missing something but the "field" labeling sounds quite confusing to me as it's describing the cell level instead of the column level. What about "Attributes" (my favorite) or "Properties"?