React component to highlight words within a larger body of text

This change exposes the chunk, index as chunkIndex, and highlightCount as highlightIndex to the HighlightTag render prop. This is useful if a user would like to apply custom styling/colors to the chunks. It could be used like this for example:

const getHighlightTag = () => ({ children, highlightIndex }) => {
    const backgroundColors: {
        0: 'green',
        1: 'red',
        2: 'blue
    }

    return (
        <mark backgroundColor={backgroundColors[highlightIndex]}>
            {children}
        </mark>
    );
};


<Highlighter
    highlightTag={getHighlightTag()}
    searchWords={[ 'hello', 'highlight', 'text' ]}
    textToHighlight={'hello, highlight this text'}
/>

The chunk and chunkIndex props are not necessary for the above example, but I thought they may be useful for someone

This change introduces a new prop called textColors. This new prop is a mapping of words to css classes and is used to apply these classes to the words.

For example: { the: 'green', of: 'blue', hello: 'orange' }

In the example, instances of the will have the class green applied to them instead of highlightClassName.

Note: I had trouble running the tests due to an npm install problem, probably with phantomjs. I'm happy to take some advice on that to make sure that the tests still pass, because I was unable to do that.

Description

This PR adds ability to render custom HTML tags / React Nodes instead of defaulting to <span> element.

Problem

Defaulting to <span> is a good idea and must have, but sometimes we have edge cases where you need to pass custom React nodes in order to provide additional functionalities. Please see the Use Case below.

Use Case

Should be able to render <a> tags whenever necessary or pass React components (such as <Linkify>: https://github.com/tasti/react-linkify) to render the links properly.

For example, we can pass in the following function:

({ children }) => {
  return (
    <div onClick={doSomething()}>{children}</div>
  );
}

This would enable custom behavior to be added to highlighted words.

For what I am doing I needed the ability to pass a pre-comparison function, in order that accented characters were matched by unaccented characters. Submitting this PR in case this is useful to you. Happy to modify if you want.

An alternative solution to #19. I'm guessing @untone is dealing with the same problem that I am - an inability to use react-highlight-words since it's .babelrc is for Babel 5 and we're using Babel 6.

See https://github.com/reactjs/redux/issues/1033 and https://github.com/gaearon/redux-thunk/pull/44 if more justification is required.

I was running webpack-bundle-size-analyzer investigating why my bundle size was getting so big and I noticed your library was taking more space than React itself ! With some digging I figured you are actually including React with this package which isn't the expected behavior when React is already a dependency of the package.

This PR adds adds React as an externals (see http://webpack.github.io/docs/library-and-externals.html) so that it's not included. main.js is now almost 37x smaller :

Before:

~/react-highlight-words $ ls -la dist/main.js
-rw-r--r--  1 loic  staff  695657 May 10 17:31 dist/main.js

After:

 ~/react-highlight-words $ ls -la dist/main.js
-rw-r--r--  1 loic  staff  18826 May 10 17:34 dist/main.js

It also adds a .npmignore so unused files don't get included in the npm package

A couple of changes:

• prop-types was in the dependencies section of package.json
• build was not generating a uglified output (so 50K instead of 15). About this I'm still wondering if this was intentional or not.

I found it rather surprising that the searchWords are treated as RegExp by default. This PR tweaks the Readme slightly so that new users are less likely to be cut on this sharp edge.

Issue #12 discusses changing this default and concludes "changing the default would require a major release"

Fixes #1 by doing a pass over the text to find all matching "chunks" for each search word. It then does a pass over these chunks to merge the ones which are overlapping. Finally, given a blob of text and a set of merged chunks, it creates chunks for each of the non-matching portions of the text. This resulting collection of matching and non-matching chunks then get used to identify each portion of the text as either a highlighted or a non-highlighted portion.

Notes on tests: I must apologise for not taking the time to learn whatever the testing framework you are using. I had some troubles getting it to run on my ArchLinux laptop for some reason. Anyhow, I did create a set of unit tests, and I tried to make it clear where each test starts/finishes by running them in an anonymous function. Hopefully it should be easy to extract these into proper tests for the JS testing framework of your choice.

In order to run these tests, I have a silly branch with an extra commit. The tip of that branch runs the tests each time the Highlighter module is imported, and prints to the console if there are errors.

It's a stepping stone PR that makes it possible to use the library with React 18:

• Provide basic support of React 18
• Remove incompatible dependencies.
• Update test configuration to temporarily suppress warnigns (render hasn't switched to createRoot yet).