Closed madeleineostoja closed 7 years ago
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?
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.
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.
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?
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.
:+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
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
:+1:
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