unittests + basic code for fuzzy search #31
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…onality Doesn't work yet b/c typescript needs to be setup. Also, this code structure is just temporary; feel free to move stuff.
SeijiEmery
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Doesn't work yet b/c typescript needs to be setup.
Demonstrates how to write typescript code (and the major, MAJOR advantages that this brings, like eg. enums, type aliases, and builtin null checks, ie. if something can be null that has to be explicitly part of the type definition), though ofc code should properly be split into at least 2 different files or something.
Also demonstrates proper unittests (I think).
Ofc some things are much more trivial (like this) to write unittests for than others; if you're writing something like an algorithm though (ie. this), then it's imperative that you write full tests first, as that'll actually reduce the amount of time you spend writing + fixing said algorithm, in order to get predictable, expected results.
In terms of code structure, this makes it trivial to add other string matching algorithms, and spanify is provided to break strings up into spans for highlighting. Obviously, this is not ALL of the functionality we need for a search bar; I was thinking we'd sort the list (according to some criteria), then lazily fetch the top N results we need that pass this string filtering / string matching test, which would actually have to be applied to multiple fields (or just concat all fields together into one string or something). We may also want even more fuzzier string matching (ie. edit distance), which we'd have to handle differently b/c case we'd sort based on that (and maybe the result of some other criteria), and then just select the top N elements.
This code structure is just temporary, so ofc feel free to move stuff.
Note: while trivial, this code is an important example of:
– delivering a small slice of code that is / will be complete: fully documented, fully tested; won't need to go back later to rewrite it; easily extensile to add other functionality; does NOT implement a full feature, but implements an important part of it.
– using TDD to properly drive development: this code is not complete (see .spanify(); tests not setup yet), but will be as soon as all the tests pass.