Setting up the JavaScript Experiment, Part 2

What we did first:

https://camelcasenoodles.blogspot.com/2019/12/setting-up-javascript-experiment.html

What's Next:

Now we need to start setting up a search algorithm.  The user will type into the Search input and look for a matching word/string.   For this part, we are only going to get it finding strings who's first letters match and giving us back a list of those matches in the console with console.log.
You can see what the log is doing if you go to your developer tools in the browser and opening up the tab for console.   Pictured below is what those steps are with Chrome.  On firefox they are very similar steps.

Step 1:  find the tools
Usually in the top right corner next to the address bar

Step 2:  Open web development in the list,  In chrome, it is linked to the first menu's "more tools" list item.  Image: The open tools, with the drop menus for 'more tools' and 'development tools' selected.

Step 3: Select the Developer tools and the extra analyzing window should pop up below your webpage.  In this you can change element styles, see the console log, and many more things.  It is an amazing way to play with your web page without making changes to the source code, or debug items that may be uncooperative. 

Image: A screenshot of the opened developer tools, and results of the console.log in the console tab.  These results are from the new code added to the first experiment set up in the blog post listed above. 

To the lab Egore!

   For most experiments it's good to start in small chunks, so for this part, we are just getting a function set up to return us results for a search of the first letter someone enters into our search bar.  The method 'charAt()' in the JavaScript code can be heavily utilized for our future search algorithm as it gets more complex.  

  With the Google Fonts, we have a list 900+ items in length, and every letter of the alphabet is represented in those items.  For this part though, we just want to get a feel for what we'll need to implement to get the top ten similar, or matching strings.  If you think about it, a lot of 'searches' like this will give you the closest matches even after the first letter, then narrow down the results.  For me, having it return 'Nothing' because it's not a perfect match is frustrating, so for my search, I'll want it to give me closest, but not necessarily exact.   

  However for the experiment, the list I have provided does not have every letter represented, so we'll be returning a 'no -match' when that first character is not found in the list.  In the Google fonts I'll be still returning a list with close matches, and just rearranging them according to what is the closest to the string the user typed into the search.  BUT.... small chunks.  Get the motor running, then fine tune the miss-fires.  

Note:

I did add some more words to the original list. 

The Code:

I had to add two javascript functions, then in the HTML have the 'onkeyup' call for our search in the element id='search' which is the user <input>.  Here are the two functions that control the search:

JAVASCRIPT

--start code block--

//------------- SEARCH THE LIST OF WORDS------------
/* We will be searching every time a person enters a character,
 * This could prove to run this function many many times, so is there
 * A way to shorten the process? 
 * A user might start with one letter, backspace to start a new first letter,
 * So we can't rely on the string we're searching for remaining constant.
 */
function search_for(astring, alist) {
    newlist = [];
    size = alist.length;
    i = 0
    
    for (j = 0; j < size; j++) {
        max = astring.length
        word = alist[j];
        first_in_word = word.charAt(i)
        first_in_string = astring.charAt(i)
        if (first_in_word == first_in_string) {
            newlist.push(word)
        }

    
    }
    if (newlist.length > 0) {
        console.log(newlist)
    }
    else {
        console.log("No match found")
    }

}

//----------- Conduct a search on keydown in the Search input-------------
function call_keydown() {
    //in html, an onkeyup="call_keydown" will trigger this function.
    element = document.getElementById("search")
    newstring = element.value
    //Retrieve the first letter match list
    //This is only to match the first letter
    search_for(newstring, search_array)


}

--end code block--

  The call_keydown() will in turn call the search when a new letter is typed into the search bar. There are some flaws to this, because it will call the search even when the 'backspace' is used.  I'm still debating if this is an issue that should be addressed or is necessary for the user and their search. 

The call_keydown() will use the search_for(astring, alist) to have the console.log results of the search through the list of words.  Remember it's only set up to search that first letter.  

The for loop will iterate through our list of words defined in the beginning of the script.  If the first letter of the word matches '==' the input value, we'll append it to a new list.   This list will be the one I manipulate to refine the results in the future experiment.  

Why?

The google fonts list of font names is over 900+ items.  My goal is to whittle that down, without changing the original list, to about 10 close matches to what the user is searching for. So in this experiment, I want to find the best way to do this, and preferably as simple as possible. Not just for my own sanity, but because the simpler a function is, the easier it is for the browser to interpret and run, making our website a happier place. 

I also have theories on data manipulation that may steer me toward not messing with the original list unless there is no other alternative.  

If your interested:

https://camelcasenoodles.blogspot.com/2018/01/theory-data-corruption.html

HTML 

--start code block--

<!DOCTYPE html>

<html lang="en" xmlns="http://www.w3.org/1999/xhtml">

<head>
    <meta charset="utf-8" />
    <!--  viewport for mobile users -->
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <!-- links to our css(optional) and javascript file-->
    <link rel="stylesheet" href="custom_js_experiment101.css" />
    <!--  THE ERROR script looked like this:

        <script type="text/javascript" src="js_experiment101.js" />

        Because the closing tag was missing, when I ran the HTML, the body was empty.
        If something has completely dissappeared from your page, HTML is probably ignoring it for some reason.
        -->
    <script type="text/javascript" src="js_experiment101.js" /></script>
    <!-- title for the page-->
    <title>javascript search</title>

</head>

<body>
    <h1> Search in an array for a close or matching string set:</h1>
    <!--  ADDED FOR TEST -->
    <h3 id="test"></h3>
    <h4> The array: ['ant', 'attic', 'anticipate', 'bore', 'boredom', 'cat', 'borealus', 'dog', 'emu', 'frog', 'snippet', 'match', 'matrix', 'mutton']</h4>
    <main>
        <!--  a search input for user interaction -->
        <form>
            <!--    ADDED  -->
            <input placeholder="Search here" id="search" onkeyup="call_keydown()"/> <!-- Function call HERE -->
            <!-- A reset button to reset search parameters-->
            <input type="reset" value="reset" />

        </form>

        <div class="deck" id="deck">
            <div class="results_card" id="results_card" style="border: solid 2px red;">

                <!-- ADDED -->
                <h3> The array word </h3>

            </div>
        </div>
    </main>
    
</body>
</html>

--end code block--

Why?

If I were to use an eventlistener, it would listen for every 'onkeyup', and I only want the search to occur if the keyup is happening in the search input.  The google fonts project has two input fields for the user, so I wouldn't want every keyup to trigger a search through our list.  

In conclusion:

  If you're using an experiment like this example to figure something out, do little pieces.  Get small components to work, one at a time, until you have it all in a neat bundle of working code.  Clean it up, debug it, throw some slime into the machine and see what cogs up.  Some people can just write code directly into their app without worry.  I happen to not be those people.   I have done it, but it feels much better to work stuff out in something that I don't worry about breaking.  This way, there is more freedom to tool around and play a bit.  If I break the experiment, it's no big deal to wipe out and start new.  Part 3 will feature getting the next characters and a list of the closest matches.  There may be a bit of LevenStein ... we'll see. 

Once you've finished your experiment and gotten everything figured out you intended to test, go ahead and work it into the application the experiment was intended for.  Or maybe it takes on it's own life and becomes an app all it's own.    

When the google fonts project is up and running online, I'll come back and post the links to github, and the online project  HERE-->  

live:

https://nelliesnoodles.github.io/Favorite_Fonts_Chingu_V15_prework/

Github code:

https://github.com/nelliesnoodles/Favorite_Fonts_Chingu_V15_prework

As always, take it, break it, burn it down,  and have fun learning.