Re: [WICG/webcomponents] The MountObserver api, an alternative lazy custom element definition proposal (#896)

Thanks, @doeixd! 

You might be right, that for those conditions that are JS-based, which includes the custom condition checker, the instanceof check, and possible the arrow-based import, that my argument about doing as much as possible in the low-level c++ code without context switching back and forth between c++ and JS doesn't apply, so we should look at the most powerful way we can chain those checks together.  That seems like a good idea, I'll give it some thought.

The import statement, for me what is important is that we have these two highly overlapping concerns addressed:

1.  The import can (optionally) be as succinct as possible, requiring only a string path, similar to the dynamic import('./my-element'), without having to resort to arrow functions.  That way bundlers and other tools (CSP, maybe?) would know precisely what to look for.  That was the thinking behind flagging that particular action separately, rather than just saying something like "do the  import inside this generic action placeholder" like the mount callback / event handler. 
2.  You could argue (I think maybe this is what you are arguing actually) that if the developer chooses not to use the string option, but instead provides an arrow function, which this proposal also supports, then code analysis will be just as hard.  But I *think* even though it is inside an arrow function, that even still, flagging it as "attention everyone, an import is afoot" will make it easier to manage things like bundling and CSP checks.  It won't involve looking for needles in the haystack.  On the other hand, once you open up that function option, I can't think of a way of validating that the logic inside is exclusively doing import work.  There's nothing stopping developers from just proceeding to load it up with lots of code that isn't import related, that gets merged into the "module" context object.  You might be onto something there, let me think further about that.




-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/896#issuecomment-2073864721
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/896/2073864721@github.com>