Class: Index

lunr.Index(attrs)

new Index(attrs)

An index contains the built index of all documents and provides a query interface to the index.

Usually instances of lunr.Index will not be created using this constructor, instead lunr.Builder should be used to construct new indexes, or lunr.Index.load should be used to load previously built and serialized indexes.

Parameters:
Name Type Description
attrs Object

The attributes of the built search index.

Properties
Name Type Description
invertedIndex Object

An index of term/field to document reference.

fieldVectors Object.<string, lunr.Vector>

Field vectors

tokenSet lunr.TokenSet

An set of all corpus tokens.

fields Array.<string>

The names of indexed document fields.

pipeline lunr.Pipeline

The pipeline to use for search terms.

Source:

Methods

(static) load(serializedIndex) → {lunr.Index}

Loads a previously serialized lunr.Index

Parameters:
Name Type Description
serializedIndex Object

A previously serialized lunr.Index

Source:
Returns:
Type
lunr.Index

query(fn) → {Array.<lunr.Index~Result>}

Performs a query against the index using the yielded lunr.Query object.

If performing programmatic queries against the index, this method is preferred over lunr.Index#search so as to avoid the additional query parsing overhead.

A query object is yielded to the supplied function which should be used to express the query to be run against the index.

Note that although this function takes a callback parameter it is not an asynchronous operation, the callback is just yielded a query object to be customized.

Parameters:
Name Type Description
fn lunr.Index~queryBuilder

A function that is used to build the query.

Source:
Returns:
Type
Array.<lunr.Index~Result>

Performs a search against the index using lunr query syntax.

Results will be returned sorted by their score, the most relevant results will be returned first. For details on how the score is calculated, please see the guide.

For more programmatic querying use lunr.Index#query.

Parameters:
Name Type Description
queryString lunr.Index~QueryString

A string containing a lunr query.

Source:
Throws:

If the passed query string cannot be parsed.

Type
lunr.QueryParseError
Returns:
Type
Array.<lunr.Index~Result>

toJSON() → {Object}

Prepares the index for JSON serialization.

The schema for this JSON blob will be described in a separate JSON schema file.

Source:
Returns:
Type
Object

Type Definitions

queryBuilder(query)

A query builder callback provides a query object to be used to express the query to perform on the index.

This:
Parameters:
Name Type Description
query lunr.Query

The query object to build up.

Source:

QueryString

Although lunr provides the ability to create queries using lunr.Query, it also provides a simple query language which itself is parsed into an instance of lunr.Query.

For programmatically building queries it is advised to directly use lunr.Query, the query language is best used for human entered text rather than program generated text.

At its simplest queries can just be a single term, e.g. hello, multiple terms are also supported and will be combined with OR, e.g hello world will match documents that contain either 'hello' or 'world', though those that contain both will rank higher in the results.

Wildcards can be included in terms to match one or more unspecified characters, these wildcards can be inserted anywhere within the term, and more than one wildcard can exist in a single term. Adding wildcards will increase the number of documents that will be found but can also have a negative impact on query performance, especially with wildcards at the beginning of a term.

Terms can be restricted to specific fields, e.g. title:hello, only documents with the term hello in the title field will match this query. Using a field not present in the index will lead to an error being thrown.

Modifiers can also be added to terms, lunr supports edit distance and boost modifiers on terms. A term boost will make documents matching that term score higher, e.g. foo^5. Edit distance is also supported to provide fuzzy matching, e.g. 'hello~2' will match documents with hello with an edit distance of 2. Avoid large values for edit distance to improve query performance.

Each term also supports a presence modifier. By default a term's presence in document is optional, however this can be changed to either required or prohibited. For a term's presence to be required in a document the term should be prefixed with a '+', e.g. +foo bar is a search for documents that must contain 'foo' and optionally contain 'bar'. Conversely a leading '-' sets the terms presence to prohibited, i.e. it must not appear in a document, e.g. -foo bar is a search for documents that do not contain 'foo' but may contain 'bar'.

To escape special characters the backslash character '\' can be used, this allows searches to include characters that would normally be considered modifiers, e.g. foo\~2 will search for a term "foo~2" instead of attempting to apply a boost of 2 to the search term "foo".

Type:
  • string
Source:
Examples

Simple single term query

hello

Multiple term query

hello world

term scoped to a field

title:hello

term with a boost of 10

hello^10

term with an edit distance of 2

hello~2

terms with presence modifiers

-foo +bar baz

Result

A result contains details of a document matching a search query.

Type:
  • Object
Properties:
Name Type Description
ref string

The reference of the document this result represents.

score number

A number between 0 and 1 representing how similar this document is to the query.

matchData lunr.MatchData

Contains metadata about this match including which term(s) caused the match.

Source: