Better way to covert String to Float Field

[ccfiel]

I have a float field, but sometimes, in actual MongoDB, it has a value of NaN, undefined, so Prisma will throw an error. My solution is to declare it as a string in Prisma and process it in the resolve function. Please take a look at the code below. Is this the best way?

function stringToFloat(value: string | null | undefined): number {
  try {
    const numFloat = parseFloat(value ?? '0');
    if (isNaN(numFloat)) {
      return 0;
    } else {
      return numFloat;
    }
  } catch (e) {
    return 0;
  }
}

ItemsAddOnsList.implement({
  fields: (t) => ({
    id: t.exposeID('id', { nullable: true }),
    baseQty: t.exposeInt('baseQty', { nullable: true }),
    qty: t.exposeInt('qty', { nullable: true }),
    sortId: t.exposeInt('sortId', { nullable: true }),
    unit: t.exposeString('unit', { nullable: true }),
    itemId: t.exposeString('itemId', { nullable: true }),
    key: t.exposeString('key', { nullable: true }),
    managedStocks: t.exposeBoolean('managedStocks', { nullable: true }),
    name: t.exposeString('name', { nullable: true }),
    price: t.field({
      type: 'Float',
      resolve: (parent) => stringToFloat(parent.price),
    }),
    rate: t.field({
      type: 'Float',
      resolve: (parent) => stringToFloat(parent.rate),
    }),
    cost: t.field({
      type: 'Float',
      resolve: (parent) => stringToFloat(parent.cost),
    }),
  }),
});

[hayes]

This looks reasonable to me. I think having resolvers for cases where your data isn't already in the format you want in your schema makes sense, are you running into any issues with this pattern?

[hayes]

You can technically set up your own Float scalar rather than using the built in one that can convert strings to the right value. This would work the same as adding a custom scalar, and you would just use string | number as the output type. You'd need to implement a serialize function that parses the strings to numbers of the vue is a string

[ccfiel]

@hayes Yup, that's what I was thinking also. What would be the best implementation? Do it resolver or do it in scalar?

[hayes]

That's pretty subjective. Personally I'd put it in a resolver, but if you are doing it a lot, doing it in a scalar might make more sense, since you won't need to repeat it all over the place. The downside is that any string will be accepted as a valid value for any float field, which reduces type safety a bit.

[ccfiel]

@hayes, thanks again!! :)