whitlockjc / json-refs

Various utilities for JSON Pointers (http://tools.ietf.org/html/rfc6901) and JSON References (http://tools.ietf.org/html/draft-pbryan-zyp-json-ref-03).

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Allow custom loader to be provided

jammi opened this issue · comments

My use-case is that I have an object of objects, for which there are no real correspending files (let's say they come from a database), let's say:

const oaData = {
  'index.foo': {openapi: '3.0.2', ...},
  'schemas.foo': {...}
};

and my refs are like:

{ $ref: 'schemas.foo#/components/schemas/foofoo' }

When json-refs is used with it like this, there's no real way to fetch such references with a processContent function because PathLoader will try to resolve to process.cwd() and of course won't find such files.

What I suggest is providing an option for a simple function that gets an unmangled uri and then either returns an object (or error) as-is (synchronous), or returns a promise (asynchronous). You could name it customLoader or somesuch.

It could even have some matcher function to provide a way to validate whether to use the customLoader or fall back to PathLoader ending up with a simplest use-case (using the oaData from above) such as:

resolveRefs(oaData['index.foo'], {
  useCustomLoader: uri => !!oaData[uri],
  customLoader: uri => oaData[uri]
}).then(buildAPI);

or let's say from an async database loader such as:

resolveRefs(oaIndex, {
  overrideLoader: uri.startsWith('mydb://'),
  customLoader: uri => dbLoader(uri).then(res => JSON.parse(res.oa_data))
}).then(buildAPI);

I guess it's time I get this supported: whitlockjc/path-loader#1