Right now we're just setting the path property on any element that has an sid / gid property. This is a risk if the user wants to use these attributes on elements that already have a path property that's used for something else. There's no standard HTML path property, but users could have a custom-element that adds it.

This could be resolved by using a Symbol, rather than a String as the property. This would protect for unknown elements.

From a simpla element's perspective, to keep the regular path property on them, as well as getting the value from simpla-paths, it would have to import the Symbol used by simpla-paths (not much weight given tree-shaking), and pass the value set by paths to it's own path property. e.g.

import { PathSymbol } from 'simpla-paths';

class SimplaText extends HTMLElement {
  set [ PathSymbol ](value) {
    this.path = value;
  }

  get [ PathSymbol ](value) {
    return this.path;
  }
}

A Symbol polyfill would also have to be bundled somewhere, as Symbols aren't supported at all by IE, AFAIK the polyfill is relatively lightweight e.g. are used by SkateJS.

Allow simpla-paths to traverse up/down the tree in attributes, using dot notation inside SIDs/GIDs. Fixes the use-case where markup structure doesn't perfectly match content structure, especially with shared code and complex content models

• foo.bar to traverse down a tree

• ..baz to traverse up a tree (additional dot for each level up)

• Can combine patterns, eg: ..baz.qux

• Can traverse in both SIDs and GIDs (obvs GIDs can only traverse down, useful for removing unecssary nesting)

• If the key accessed with traversing doesn’t exist, it is created as per usual

The basePath argument to SimplaPaths.observe() is confusing - intuitively you specify a leading slash, like /base/path, but that results in the following //base/path which is invalid. Likewise I was just guessing whether I should include a trailing slash or not, if I had it would have resulted in /base/path//sid which is also invalid.

I think the fix for this is for observe() just to sanitize whatever it gets in basePath (within limits), particular in regard to leading and trailing slashes.

Very unscientiffic test, but ran Fetch as Google on simplajs.org, and the only thing that rendered was the one bit that isn't using simpla-paths (the footer)

Might be worth profiling, and maybe even suggesting to deprecate this in favour of build-time path construction. Or, add a prerender buildstep to simpla-paths, so you can maintain easy clientside path recalculation

Right now it's impossible to observe path changes on builtins, because simpla-paths doesn't fire any events to let us know when things change.

Should fire a path-changed event originating from the element set that looks something like

{
  detail: {
    path: ...
   }
}