Cell Search Engine

[gliechtenstein]

Inspired by the discussion started by @kingoftheknoll on this thread I started thinking about a "cell search engine" (just a rough concept for now).

Basically, I think Cell should be kept decentralized, but it would be nice to have some sort of a centralized index or registry that makes communication easier and more efficient. By "search engine" I just mean keeping a reverse index of the cell nodes and their genes, but I guess potentially this can be expanded to create a universal "cell search engine" (but that's more like a sci-fi story at this point, so let's not go there yet 😄)

Anyway, this could be implemented in either of the following format (In the order of desirability):

1. Completely separate library: Built on top of cell utilizing already exposed APIs (If you look closely we store a lot of metadata on the genotype so this may be possible) but not touching Cell itself. Since it's completely decoupled from Cell, may even be reusable in scenarios outside of Cell as well.
2. Extension: built on top of Cell, but maybe Cell can expose more APIs to make this easier
3. Built into Cell: Built into cell itself as an optional structure.

I think a good approach is to try the first approach (completely separate library) and then think about other options if there's a roadblock.

Some ideas

Just sharing some of my ideas so far:

1. HTMLElement.prototype.$find / HTMLElement.prototype.$where

These used to exist in the early days of development, but I took them out right before releasing. But I think it makes sense to share it in this context. Basically these are convenience methods you can use instead of querySelector or querySelectorAll.

Select multiple items

this.$where(".items").forEach(function(item) { item._refresh(); });

Select one item

this.$find("#counter")._update(this.value);

2. Filter function for $find and $where

I took out these methods because the utility (basically just a convenience wrapper around querySelector and querySelectorAll) didn't justify having to pollute the node's attribute namespace.

But it may make sense if there's some additional functionalities for these methods. Which is where the "cell search engine" comes in.

In addition to doing something like:

this.$where(".items").forEach(...)

What if we could do the following:

this.$where(function(item){
  return item._done === true;
})._remove();

Why use the prototype methods? (Comparison with jQuery)

One nifty side effect to this approach is it's kind of like a cell-native way of doing extensions. In case of jQuery they implement extensions by letting you attach functions to $.fn.

Cell is actually very similar to jQuery except that it's similar in an exactly opposite way. Instead of wrapping an jquery object on a node, we're wrapping a gene objects inside a node.

So in this context, these $find and $where functions could be thought of as sort of "cell extensions", which means maybe we can expand on this concept to create a nice extension system.

Conclusion

This is just a rough idea I just randomly came up this morning, so just thought I would share. It should be possible to index the entire DOM tree since each node contains a full Genotype. (You can try by querying $node.Genotype and you'll see the gene from which the node was constructed)