Upgrade to ES6: Arrays with added prototype properties break

[joshjung]

Note: this bug actually exists in the HashArray code but I'm putting it here since this library is the primary user of HashArray.

For example, if you do this somewhere in your code:

Array.prototype.range = function() {
  ...
};

The HashArray breaks here:

  //-----------------------------------
  // add()
  //-----------------------------------
  addOne: function (obj) {
    var needsDupCheck = false;
    for (var key in this.keyFields) {
      key = this.keyFields[key];
      var inst = this.objectAt(obj, key);

This was written eons ago and really just needs to be updated to ES6 or TypeScript as per someone else's request and fork.

Anyway, putting this ticket here so I can take a look at it when I have some free time. In the meantime, TrieSearch does not work if you do fancy global manipulations to the Array.prototype.

[jsantos42]

@joshjung Do you want me to try to rewrite the whole thing in TS and bump the package major version? I figured you wanted to keep backwards compatibility, so I didn't do it right from the start 😅

[typhonrt]

@jsantos42 You might want to hold off on that.. I've already done a major rewrite, but have been sleeping on announcing anything. With benchmarks that are included it is 2-3 times faster than the original. Also reactive querying / Svelte store integration / doesn't require Svelte to use reactive capabilities w/ JS only.

My effort combines a modernized hash-array and trie-search packages.

https://github.com/typhonjs-svelte/trie-search
https://www.npmjs.com/package/@typhonjs-svelte/trie-search

[joshjung]

@typhonrt Is your implementation tightly coupled to Svelte? It appears to be. I've been using the trie-search on lots of packages but many of them were React or node.js. Would love to get your improvements out there but not tightly coupled to Svelte if possible!

[typhonrt]

@typhonrt Is your implementation tightly coupled to Svelte? It appears to be.

Not so much / not at all. The reactivity granted is all based on the Svelte store contract which is essentially a lightweight observer contract. IE a subscribe method that takes a callback function and returns an unsubscribe function. While this pattern is immediately usable in Svelte it is fully compatible with raw JS usage and should be possible to adapt to other reactive frameworks.

In the main NPM release the scant access to svelte/store to pull in the basic helper functions for the store contract are compiled into the release / no dependence on Svelte itself. DynArrayReducer seen in the reactive query implementation has no Svelte dependencies / implements the Svelte store contract directly / is a custom store.

There are ~3 dependencies on various other NPM packages which are mostly utility oriented.

The general reason why I didn't get in contact sooner though are the additional architecture aspects that I implemented to make things smoothly work with a larger framework I put out. You'll see imports that reference #runtime/util/object and others. I use modern package.json features like imports to remap those paths to the independent packages they represent in my framework which re-exports those packages. The main @typhonjs-svelte/trie-search package on NPM will have those as basic dependencies.

I create a separate build of the package that I directly export in my framework behind the scene that doesn't do the imports substitutions in the build that I can export directly in my larger framework where all of the #runtime/XXX paths are from.

---

Besides the performance improvements (mostly due to switching to Map / not using hash array for caching and a Map based LRU implementation, etc) one of the neat features is using an iterator for string tokenization. You can provide a separate iterator implementation that can tokenize unicode ƒor instance. I have this demoed in the tests from a separate package I put out
@typhonjs-utils/unicode. This package also being a modernization effort of the best defunct OSS efforts for unicode splitting that I found.

This allows the generated trie to be compact for unicode use cases.

[joshjung]

Okay, I think I understand. I would just highly recommend not branding the naming and such as Svelte or else people will think they can't use it unless they also use Svelte!