fix(ui-tablemode): unable to edit tables with old types

[skamril]

ANT-1667

[hdinia]

Their is a version handling error on studies < v8.3 for the field adequacy-patch-mode
that returns a 422 validation error on updates, for all fields
error: "adequacy-patch-mode none is not an allowed value"

other than that the fix for aliases seems working 👍🏼

[hdinia]

I think their is a small confusion between "columns" and "fields", it make sense in the UI but that is a bit misleading in the code, is this intended ? (not just in this file)

for this file here's a suggestion:

export const TableType = {
  Area: "areas",
  Link: "links",
  Thermal: "thermals",
  Renewable: "renewables",
  ShortTermStorage: "st-storages",
  BindingConstraint: "binding-constraints",
} as const;

export const TABLE_TYPES = Object.values(TableType); // iterable constant

// Deprecated types (breaking change from v2.16.8)
export const TABLE_TYPE_ALIASES = {
  area: TableType.Area,
  link: TableType.Link,
  cluster: TableType.Thermal,
  renewable: TableType.Renewable,
  "binding constraint": TableType.BindingConstraint,
};

export const FIELDS_BY_TYPE = { // or COLUMNS_BY_TYPE
  [TableType.Area]: [
    "nonDispatchablePower",
    "dispatchableHydroPower",
    "otherDispatchablePower",
    "averageUnsuppliedEnergyCost",
    "spreadUnsuppliedEnergyCost",
    "averageSpilledEnergyCost",
    "spreadSpilledEnergyCost",
    "filterSynthesis",
    "filterYearByYear",
  ],
  [TableType.Link]: [
    "hurdlesCost",
    "loopFlow",
    "usePhaseShifter",
    "transmissionCapacities",
    "assetType",
    "linkStyle",
    "linkWidth",
    "comments",
    "displayComments",
    "filterSynthesis",
    "filterYearByYear",
  ],
  [TableType.Thermal]: [
    "group",
    "enabled",
    "unitCount",
    "nominalCapacity",
    "genTs",
    "minStablePower",
    "minUpTime",
    "minDownTime",
    "mustRun",
    "spinning",
    "volatilityForced",
    "volatilityPlanned",
    "lawForced",
    "lawPlanned",
    "marginalCost",
    "spreadCost",
    "fixedCost",
    "startupCost",
    "marketBidCost",
    "co2",
    "nh3",
    "so2",
    "nox",
    "pm25",
    "pm5",
    "pm10",
    "nmvoc",
    "op1",
    "op2",
    "op3",
    "op4",
    "op5",
    "costGeneration",
    "efficiency",
    "variableOMCost",
  ],
  [TableType.Renewable]: [
    "group",
    "enabled",
    "tsInterpretation",
    "unitCount",
    "nominalCapacity",
  ],
  [TableType.ShortTermStorage]: [
    "group",
    "injectionNominalCapacity",
    "withdrawalNominalCapacity",
    "reservoirCapacity",
    "efficiency",
    "initialLevel",
    "initialLevelOptim",
    "enabled",
  ],
  [TableType.BindingConstraint]: [
    "enabled",
    "timeStep",
    "operator",
    "comments",
    "filterSynthesis",
    "filterYearByYear",
    "group",
  ],
} as const;

[skamril]

In the context of Table Mode which is a table, it makes sense to talk about columns

[hdinia]

I agree it make more sense for the UI, but in the code we reference "fields" as they are "columns" don't you think it's misleading ?

[skamril]

Where?

The signification is: create a table with this specified columns, then we will have multiple rows with editable cells (or fields). So we will have multiple fields for a column.

[hdinia]

No problem about this, my point was just about columns vs fields in the code. Can you consider refactoring to use an enum-like like in the provided example ? TableType

[hdinia]

can you consider moving constants.ts and types.ts from the api folder to the TableMode component folder ? I think it has nothing to do with the api

[skamril]

If you read carefully, you will see that there are used for typing API function parameters: columns and tableType

[hdinia]

just import them, these 2 files especially constants should live in their local component folder

[hdinia]

or better we can do like other components and put this in the utils of the component as I suggested in the first PR

I know you dont agree with that but I would have also put the api methods in the utils of TableMode (as it's very specific)

[skamril]

just import them, these 2 files especially constants should live in their local component folder

No, it's the component that is based on the API, and not the opposite.
And constants.ts is used by types.ts, so it's not specific for the component.

I know you dont agree with that but I would have also put the api methods in the utils of TableMode (as it's very specific

No I think it's better to keep all API functions in the "service" folder:

• It follows the principle of separation of concerns, where API-related logic is isolated from the components responsible for rendering UI.
• Better code organization: to avoids having certain functions in the folder (those that are reused across multiple components) and others not. For consistency.
• Services can be easily tested independently of UI components, enhancing testability and maintainability.

[hdinia]

services/api folder should only contain api methods in their dedicated file, the rest is often related to the component. like in this case you have all the constants of tablemode like TABLE_MODE_COLUMNS_BY_TYPE in the api folder. Sorry but it does not make sense here.
Ok for the api methods if you prefer to keep them in a dedicated file inside service folder (but as they are very specific to TableMode I think it's better to regroup them with the utils of that component) it avoid having a file just for 2 methods

[skamril]

Their is a version handling error on studies < v8.3 for the field adequacy-patch-mode that returns a 422 validation error on updates, for all fields error: "adequacy-patch-mode none is not an allowed value"

other than that the fix for aliases seems working 👍🏼

Effectively it's a bug, I will create a JIRA issue for @laurent-laporte-pro