Could reman column/prop name?

[thearabbit]

Ex:

My Nam | Date of Birth
...... | ............
---
// Output
[
{otherName:......, dob:....}
]

[stevetarver]

Can you describe your use case? Are you consuming an excel spreadsheet where you don't have control over column names? Something else? Want to understand all use cases before I try to implement a solution.

Possible strategy: create another option as a map of excel key names to output keynames

[thearabbit]

I would like to change my excel Header Name (not column name). For example: Column A is First Name (Header Name) change to otherName props in json converter.

[stevetarver]

Thanks, mistyped "column names", meant header.

Can you help me understand why you can't just change the excel spreadsheet to use the key names you want? This helps me improve my understanding of all use cases so I can design a solution that would suit your situation and possibly others.

[stevetarver]

@thearabbit, implementation will take a bit of work. I am starting a new job and don't see having time for this in the foreseeable future.

The simplest solution I see is to implement a post-processing step that transforms the current output to your desired output. Designing a general key rename strategy is more complex when you consider arbitrary list and object traversal.

I am leaving this issue open because it is an interesting feature. I can see business staff owning a spreadsheet and developers needing that to match API parameter names, database names, etc.

[stevetarver]

Implementation notes:

Provide key name translation - from spreadsheet key (col or row) to internal name.

Could be implemented as another option that contains a complete, ordered list of desired key names. Better yet, a key name to json path map to provide a more general solution.

Questions:

• Where to implement the translation? Probably during key name parsing so output always matches desired output and to allow general data reorganization.
• How much data re-org should be supported? Omit keys seems useful. Duplicate keys? Other?
• Do we really need to handle the general case? For the business owning the spreadsheet use case, this should always be a flat object definition.
• Is the general solution worth the effort? The above example is simple object names but we need a more general approach to handle nested objects and lists. Getting the spreadsheet names to match json paths may give developers problems and generate more support requests.