To be true, publishing one is relatively simple. But getting an idea for one, which could prove to be useful to the community (in theory at least ;) is relatively harder. There’ll already exist an npm module for most problems we could think of. In fact, like how apple trademarked “There’s an App for that™”, Npmjs could file a trademark for “There’s an npm module for that”.
Coming to the actual story… I was developing a react native application a few weeks back. I had to develop a custom component which would enable me to search a
FlatList since there is no built in support for search. Then, this idea of releasing it as an npm module was bugging me. Because, finally I had something which could be a little useful to someone facing a similar problem.
So, I started making the component much more generic and added support for
SectionList as well. Then I began exploring ways of releasing the package.
The first step is to initialise an npm project using
npm init and providing it with necessary info.
The next step is to determine the modules which our package will be dependent on. In my case it was just
react-native. But since, anybody who would be using this npm module would be doing so in their react-native project, they must already have
react-native installed. So, these must be added to peerDependencies instead of dependencies. Apart from these I didn’t have to use any other modules since the problem was relatively simple.
Then we would have to worry about versioning our modules, so that we could release bug fixes, feature updates.. with ease. The standard is to follow semantic versioning.
The patch version must be incremented when do a bug fix. Minor version when we do some minor feature enhancements without breaking the api. Major version change occurs when we do a** breaking change** to our module.
The next step is to organise our code. The entry point would be the one we specified in package.json. By default it’d be index.js. We could organise it in whichever way we find easy.
The final step is to prepare a useful README.md so that, people who actually would want to use our package fell at ease.
Once we have everything in place, we’ll have to use check if our package really works. Since its not published yet, we’ll have to test it by installing by giving it the file path instead of the name of the package. Something like
npm install <file-path> would do the trick.
If everything works fine, we’re good enough to publish it to npm. Its as simple as
npm login && npm publish if we have an account with npmjs already.
Here's the link of the modules in npmjs.
I also went a step ahead and created a react-native application which demonstrates the functionalities of this module. This application also helped me a lot in the documentation efforts.
- I’ll have to write unit tests using jest. I began testing my components with jest snapshots. But I just wish to be sure so that I write unit tests actually solve to be useful instead of writing them for the sake of it.
- Once jest tests are ready, add a CI preferably Travis.
- Adding support for highlighting the text matching the search term.
Feel free to try out this module. Any constructive feedback / pull requests are
A Wrapper around FlatList and SectionList with search feature.
A powerful wrapper around React Native FlatList and SectionList to provide built in search feature
react-native-searchable-list is designed to be simple yet a powerful wrapper around react native's FlatList and SectionList components to provide them with search functionality.
npm i react-native-searchable-list --save
||Data for the FlatList||
||Searching Term being input by the user. Typically this will be a state variable bound to a text input||
||Attribute to be searched in case of array of objects. This will be empty in case of a simple array data||
||Case sensitive / Case insensitive search. By default this will be set to true||
By default the
SearchableFlatList also inherits all the props of a React Native
FlatList. You could use virtually any props you would with a FlatList.