changed the searchbar to functional

[VarunMotiyani]

Fixes #issue-number

Changes:

I have verified that this pull request:

• has no linting errors (npm run lint)
• has no test errors (npm run test)
• is from a uniquely-named feature branch and is up to date with the develop branch.
• is descriptively named and links to an issue number, i.e. Fixes #123

[welcome]

🎉 Thanks for opening this pull request! Please check out our contributing guidelines if you haven't already.

[lindapaiste]

I'm really thinking through this effect as I go back and forth on whether it's good or bad. You're the only one who thought to include this here are we didn't have this logic in the class component version. It definitely shows a lot of foresight on your part to think about this 👍.

The situation where the searchTerm props changes based on some external factor doesn't come up in practice with the way that we are currently using the Searchbar component, as all changes are initiated by the component itself. But I'm all about separation of concerns and designing flexible and reusable components. The current component has the limitation that it will ignore any changes to searchTerm after mount and you've removed that limitation.

The main reason that I'm hesitating is a fear that this might interact badly with the throttle. I constantly have to remind myself of the difference between debounce and throttle so maybe it's not an issue. I'm concerned that there might be some pending changes which haven't been submitted at the time that searchTerm prop gets updated. Like if I'm trying to type "abc def" and the throttled submit goes through with "abc" but in the meantime I've typed " def" but now it's reset back to "abc". I'm not sure if that could happen.

[raclim]

Thanks for your work on this, this seems okay to me so far!