A
arktype•2d ago
nateiler

Partial parse

Once in a while we encounter some data that's been stored away and the schema has changed over time. I'd like to parse it but also be forgiving enough to return the partially parsed schema. Something like this: 
import { type } from 'arktype';

const test = type({
  foo: type("string.numeric.parse"),
  bar: type("number"),
  baz: type("string.date.iso.parse")
});

// bar is expected to fail
const out = test({ foo: '1', bar: "2", baz: "2011-10-05T14:48:00.000Z" });

if (out instanceof type.errors) {
  // log errors to fix after the fact

  // ctx is protected, but ctx.root is useful?
  const partiallyParsed = out.ctx.root;

  console.log("Partially parsed data", partiallyParsed);
}
import { type } from 'arktype';

const test = type({
  foo: type("string.numeric.parse"),
  bar: type("number"),
  baz: type("string.date.iso.parse")
});

// bar is expected to fail
const out = test({ foo: '1', bar: "2", baz: "2011-10-05T14:48:00.000Z" });

if (out instanceof type.errors) {
  // log errors to fix after the fact

  // ctx is protected, but ctx.root is useful?
  const partiallyParsed = out.ctx.root;

  console.log("Partially parsed data", partiallyParsed);
}
6 Replies
ssalbdivad
ssalbdivad•2d ago
ArkType works based on a set of deterministic rules like TypeScript, so there's no built-in way to do what you're describing. One option would be to iterate over the properties of your object and build a result yourself depending on which ones are valid/invalid. Sidenote, you don't need to wrap the nested properties in type- you can just refer to the strings directly: 
const test = type({
  foo: "string.numeric.parse",
  bar: "number",
  baz: "string.date.iso.parse"
});
const test = type({
  foo: "string.numeric.parse",
  bar: "number",
  baz: "string.date.iso.parse"
});
nateiler
nateilerOP•2d ago
Gotcha.
Re: sidenote - Is there any performance benefit of "string.numeric.parse" vs type("string.numeric.parse")
ssalbdivad
ssalbdivad•2d ago
Yes, it is somewhat faster to initialize if you don't inline the type call The difference isn't super significant though. The biggest thing is that due to a quirk of VSCode's language server, autocomplete is much slower for shallow strings like type("str") than for nested strings like type({ foo: "str" }), so the DX is a lot better for a few reasons without the extra wrappers
nateiler
nateilerOP•2d ago
Could I also get a nudge in how to get the type inference within a parser wrapper? 
function parseWrapper<t extends type.Any>(schema: t, data: unknown) {
  const out = schema(data);

  if (out instanceof type.errors) {
    // TODO - extra processing
    throw out;
  }

  return out;
}

const test = type({
  foo: "string.numeric.parse",
  bar: "number",
  baz: "string.date.iso.parse"
});

// ?? data = any
const data = parseWrapper(test, { foo: '1', bar: "2", baz: "2011-10-05T14:48:00.000Z" });
function parseWrapper<t extends type.Any>(schema: t, data: unknown) {
  const out = schema(data);

  if (out instanceof type.errors) {
    // TODO - extra processing
    throw out;
  }

  return out;
}

const test = type({
  foo: "string.numeric.parse",
  bar: "number",
  baz: "string.date.iso.parse"
});

// ?? data = any
const data = parseWrapper(test, { foo: '1', bar: "2", baz: "2011-10-05T14:48:00.000Z" });
ssalbdivad
ssalbdivad•2d ago
nateiler
nateilerOP•2d ago
Thanks for sharing; still struggling with the general concept there. Might have to wait for your updates to come out and see if that helps

Did you find this page helpful?