Values should be the same data structure

[MartinDawson]

Description

If you do getCellValue on an invalid cell then it results in this:

{
  address: "Sheet1!L3"
  message: ""
  type: "REF"
  value: "#REF!"
}

Whereas if you perform getCellValue on a valid cell it produces a non object like this:

  22

Instead of switching data types it's always better to keep consistent and produce the same data type in my opinion so that users don't have to do if statement checks (and also because it's just more developer friendly), in this case I think getCellValue should always return an object like so:

{
  value: "#REF!#
}

Or if it's valid:

{
  value: 22
}

This means that we don't have to do weird checks like !value.type && ... or something if we want to check that the cell has computed correctly.

[wojciechczerniak]

That depends on your implementation. I don't think that nesting the value will solve a problem here. Since { value: * } may be of any type it will require those additional checks anyway. We will just move the type checking somewhere else.

My take is to use an abstraction over 3rd party lib and have a getValue method that will return correctly formatted value that my presentation layer requires. With a single place to make all the checks and format value as I please this is not an issue.

---

Although, it may be a good idea to take a closer look at toString(), valueOf() and [Symbol.toPrimitive](hint)

class DetailedCellError {
  constructor(public value) {}

  toString(): string {
    return this.value
  }

  valueOf(): string {
    return this.value
  }

  [Symbol.toPrimitive](hint): string {
    return this.value
  }
}

Result:

const detailedCellError = new DetailedCellError('#REF!')

console.log(+detailedCellError)        // "#REF!"
console.log(`${detailedCellError}`)    // "#REF!"
console.log(detailedCellError + '')    // "#REF!"

Note: We need a feature check for [Symbol.toPrimitive] as it's not supported by all the browsers. I think that toString and valueOf may be enough, toPrimitive calls them internally

[MartinDawson]

Okay, that makes sense. Thanks!

[sequba]

Please note that HyperFormula feature requests have been moved to the Handsontable forums:
https://forum.handsontable.com/c/feature-requests/13
GitHub Discussions will be locked, but will remain public for reference. If you don't see a matching feature request in the Handsontable forums, please create a new one and link any previous GitHub discussion or issue.