FuseOptions<T> prevents nested key search

Version: 3.3.0 Type: Potential Bug

Hi,

With the recent addition of typing to FuseOptions<T> and Fuse<T> nested key search is now giving Typescript compile errors.

The particular culprit is this line in the FuseOptions<T> interface

keys?: (keyof T)[] | { name: keyof T; weight: number }[];

An example of how this was used in my application:

  fuseOptions: FuseOptions<Template> = {
    shouldSort: true,
    threshold: 0.6,
    keys: [
      { name: 'metadata.title', weight: 0.8 },
      { name: 'metadata.category', weight: 0.1 },
      { name: 'metadata.summary', weight: 0.1 },
    ],
  };

Where metadata was a key in template and title is a key in metadata. This is no longer allowed by the interface. As a temporary solution I’ve included a // @ts-ignore above the fuseOptions definition and functionality is fully #restored.

[favna]

@mmajko #309 and #310 have been created to cover deep nested keys. Furthermore https://github.com/piotrwitek/utility-types/issues/85 has been created to provide an even better solution, although that won’t be any near-future addition likely.

[ceymard]

Unfortunately such a thing is not possible. Typescript has no idea of how to handle path specifications since they’re completely implementation specific.

My best guess is that we should then go back to string instead of keyof T and forego the <T> in the type.

The sad thing about that is that you lose the robustness that comes with checking that the name indeed does exist.

I don’t know if the library supports it, but a good solution imho would be able to specify extractor functions. Not only would that probably be faster than parsing a path and resolving it, this would allow for some pretty strongly checked typing in typescript.

The implications is that a key could then be either specified by a string or a function.

This is the way that this could work ;

// An extractor is either a key for the object or an extracting function
// Here, I supposed the algorithm handles null or undefined
// values -- I suppose it does since path specifying can end up with non-existant properties
type Extractor<T> = keyof T | ((obj: T) => string | null | undefined)

// FuseOptions would become
interface FuseOptions<T> {
  // ... all the rest
  keys: Extractor<T>[] | { name: Extractor<T>; weight: number }[]
}

// By the way, I'm not clear on if we can mix simple keys with weighted ones.
// In this case, keys would be :
// (Extractor<T> | { name: Extractor<T>; weight: number })[]

  fuseOptions: FuseOptions<Template> = {
    shouldSort: true,
    threshold: 0.6,
    keys: [
      // This way, all the properties are properly checked. We are certain that they exist,
      // and if one day the code changes for the metadata object, this code will then
      // become an error, as it should.
      { name: t => t.metadata.title, weight: 0.8 },
      { name: t => t.metadata.category, weight: 0.1 },
      { name: t => t.metadata.summary, weight: 0.1 },
    ],
  };

  // Even better, when using the fuse constructor, you don't have to type everything explicitely
  var my_list = /* ... */ // my list gets a type thanks to the compiler inference

  // All the following is checked since typescript infers T from my_list's type.
  var fuse = new Fuse(my_list, {
    shouldSort: true,
    threshold: 0.6,
    keys: [
      { name: t => t.metadata.title, weight: 0.8 },
      { name: t => t.metadata.category, weight: 0.1 },
      { name: t => t.metadata.summary, weight: 0.1 },
    ],
  });