Supporting querySelector

[rigor789]

Figure out if we can support querySelector in nodeOps. It is used by internal components like Teleport (was Portal) - which would be nice if we could support them.

Seems like we can pass element's to the target as well, but from a DX perspective, it's easier to pass an element id.

Trouble is, NativeScript has the getViewById method on it's Views, but it's scoped to the views children as far as I know - how can we find an element globally?

• Can we fake it with a map of id's with our NSVElement class?
• Should we support non-id selectors? (class, complex selectors etc.?)
• If not - we should warn if the passed string is not in the form of #someid) (not sure if the hashtag is required/passed)...

[msaelices]

For the record, we could base our code in this nativescript-dom unsupported plugin (see the logic in the dom.js file)

@rigor789 IMHO, I would consider this as a nice to have feature, as I don't find it as important to find some DOM node in a mobile app compared with a SPA application or Vue instance embedded in a full HTML page.

So, if we are looking into the motivation for Teleport, the main reason is to be able to add dynamic behavior outside the DOM tree managed by the root Vue instance (typically the <div id="app">...</div>, so If we are not using a SPA and embedding a Vue instance in a part of the HTML page, we could inject dynamic markup in some other part of the DOM.

But this is not the case in NativeScript apps. All the template is always under the Vue control and there is NO markup outside it.

In that sense, I would usually implement core features first and would take this kind of features after making sure the framework is solid enough

What do you think?

[rigor789]

I think nativescript-dom would be overkill - the main motivation here is to be able to use Teleports. These do have uses in NativeScript - think of being able to write modals (custom ones that overlay the app with GridLayout and not with $showModal) that have their contents, state etc managed inside the component, but are rendered in one of the parent components (closer to root).

And sure - this is a nice-to-have, and not a blocker. We can visit this anytime in the future!

[msaelices]

I was not proposing including nativescript-dom but looking at its code to see how to get NS components based on IDs or classes. I should not use the base our code in... in my previous comment :)

I'm still not sure of the use of teleport as we manage all the template with Vue instances but, we could also use teleport passing the HTMLElement, so I guess that passing the NSVElement would maybe work here.

[rigor789]

Right - I got it the first time! Just thought that the implementation of nativescript-dom is more than we'd need for this to work. A simple Map of id -> element would be enough for Teleports!

An example for where Teleports could be useful. Let's say we have this component somewhere nested in a <Page>

<template>
  <StackLayout>
     <FormElements...>
     <CustomModalThing v-if="showCustomModal">
        <SomeStuffForModal :somePropWeBindFromHere="someProp" />
     </CustomModalThing>
  </StackLayout>
</template>

We can now render <CustomModalThing> with a Teleport as it's root tag and a slot, so it can be added to the view tree somewhere else, in this case outside the Frame which actually contains the <Page> from above.

<template>
  <GridLayout>
     <Frame />
     <GridLayout id="teleportTarget"/> <!-- CustomModalThing would get rendered here -->
  </GridLayout>
</template>

[msaelices]

@rigor789 got it! Thanks for your explanation.