Should fire event on path change

[madeleineostoja]

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: ...
   }
}

[bedeoverend]

What's the use case for firing events on intermediary elements? And just to clarify, you mean for just any arbitrary element, e.g. a div with an sid / gid attribute?

[madeleineostoja]

Yep any element that simpla-paths touches - use-case is for being able to hook into blocks changing their paths, without needing that block to be a custom element.

Because remember that all intermediary elements fulfill the role of old simpla-block, so for things like blogs, pages, etc it would be important to be able to react to their changes.

[bedeoverend]

But what's the scenario where you need it? Just cautious - want to keep this lib as trim as possible + not (potentially) flood the DOM with events.

[madeleineostoja]

Well, came across it building a demo without pointless custom element.

But a more useful use-case - building a simplified blog as follows:

<div id="blog" gid="blog"></div>

<script>
document.querySelector('#blog').addEventListener('path-changed',(e) => {
  Simpla.find({ parent: e.detail.path })
    .then(result => result.items.forEach(... // construct post templates
});

Am I missing something? You could only interact with blocks imperatively by listening for when their path is defined right?

[bedeoverend]

No no, definitely doable, easy enough and that's how it'd happen, I just wonder how much of an impact it could have, and whether it's worth making it a core feature. It would mean if you change a top level element's path (via sid / gid), all descendants would also have their paths changed, which could be a lot of events getting fired at once.

Honestly, don't know how much of an impact it would be - I'm just very cautious about perf given simpla-paths is needed to initialise all content. But probably worth taking a crack, can put it behind a config option if needed.

[madeleineostoja]

:+1:

I didn't think firing events added any meaningful perf weight? I mean, even on the most complex of sites you'd be firing what, 100 events? 200? I don't think that would cause any noticeable difference compared to setting the prop and fetching data

[bedeoverend]

Yeah, I think you're right. I'll do a quick benchmark when I do it, and if I see any difference, I'll just add it in as an optional config thing - switched off by default

[madeleineostoja]

:+1: