1

As an exercise for myself to practice my JavaScript "skills" I'm trying to write a client-side filter. It should be able to filter "content blocks" as the user types.

By "content block", I mean a list of DomElements that each contain at least one text node - it is possible that they contain more, and even a different amount of text nodes, nested inside other nodes, etc.

I've thought of 2 approaches:

  1. On page initialization, scan all nodes and store all the text in some kind of Map or a tree.

  2. Simply iterate over every item and check whether it has the string to search/filter for. One could add performance here by caching, only filtering the current remaining items if text is added, etc.

Obviously, if the number of nodes is really big, option 1 will take a while to build the 'index' but it will perform faster once it is built. Option 2 however will be available right on page load since no initialization is performed. But of course it will take longer to search.

So my question is: what is the best approach here? And how would one implement 'caching' and/or 'index'?

  • When you are just trying to filter a list of dom elements, creating some sort of index is probably going to be overkill. Plus an "index" is such an ambiguous word here. It seems like you are trying to say that you would, pre-process the content on init. Creating a hash of elements that can be easily iterated over and over again each time something is searched for. – johnnymonster Aug 19 '14 at 18:42
  • wel yeah. filtering out certain tags. For instance the labels, ... – Pinoniq Aug 19 '14 at 20:16
  • This is screaming DAG to me. Don't have enough time for a thought out answer but hopefully Google can help you put together an idea. – Demian Brecht Jul 16 '15 at 7:52
1

I believe that, a mix between both would be great.

First time it will build the index while doing the search. It will take a little more time to search, but after it will search much faster by the built indexed cache.

Thinking in the nested data situation, and considering that the search will be done a lot of times, i would make a cache not indexed, in the same tree disposition of the data, and a cache of search results.

e.g.

The result cache should be indexed by search results (less first)

  1. User search first time for javascript, in the end of the search there will be

    • a list of all texts to search linearly
    • a result list for javascript
  2. User search for nodejs, in the end of the search there will be

    • a list of all texts to search linearly
    • 2 result list (1 for javascript and 1 for nodejs)
  3. User search for javascript nodejs, it will search in the smallest list and, in the end of the search there will be

    • a list of all texts to search linearly
    • 3 result list (1 for javascript, 1 for nodejs and 1 for javascript nodejs)
  • And what kind of 'index' would be used? – Pinoniq Jun 20 '14 at 13:37
  • @Pinoniq added a example for indexed cache – Caputo Jun 20 '14 at 17:03
-2

I would assign an index by placing a property on each element after putting them in some type of list or array.

textArray[index].Index = counter; counter++;

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.