We Keep Coding

How to dynamically access children of a slot

Let's say I have a SearchForm Component that has a Reset button, as well as a slot to include any desired SearchField Components. When I click SearchForm's Reset button, I'd like to call each SearchField's reset method, but I'm having a hard time understanding how to do this dynamically... I obviously don't want to add refs to each SearchField because these aren't static and can change when using the SearchForm in some other part of the application. Fiddle for example.
In Vue2, it seemed liked there was some sort of $children property, but that was taken out in Vue3. I was thinking I could potentially use querySelectorAll to access all "input" elements, but I didn't see how I could access the DOM element's component instance (similar to jQuery's $ selector). If I access the $slots.default() and loop over it, I get some weird object that isn't a component instance... or rather, it doesn't have the typical properties that the component instance has, and I have no clue how to access the actual instance from here.
It's also possible I'm not thinking in a Vue-centric way, as I'm new to the framework, so how can I solve this issue?

I've come up with this solution, but I don't like it, as it adds some minor coupling. Basically, I listen for when the field is created, check its parent, and if it's a form, I push it onto the array of children. Then when the parent's reset is called, it loops through its children. This is a fragile approach because it requires the direct parent to be the form... if the field was nested inside of another component, it won't be added to the form's fields. I'm also pretty sure this breaks the best practices of the framework. It's a shame there doesn't appear to be a way of accessing child instances (without being forced to use ref)... that seems like it'd be desired by a lot of devs.

I came up with yet another way, but once again, seems a little shady because I'm accessing the DOM element's private property __vueParentComponent. I like it better than the previous answer because it's not coupled, and I can use getElementsByTagName. Fiddle for reference. This is the relevant code that I added as a method in SearchForm:
getFields() {
const fields = this.$el.getElementsByTagName("input");
// getElementsByTagName returns an HTMLCollection, which doesn't have map,
// so let's use spread to make an array and use map
return [...fields].map((fieldEl) => {
return fieldEl.__vueParentComponent.proxy;
});
}

Last solution... this one seems to be more stable and the proper Vue way. You use provide/inject; the parent provides the value, and the child injects it, so it can use it. Vuetify does something similar, but they have their own register and unregister methods, which I've created in the Fiddle but as a rudimentary implementation. The only caveat being if you're using TypeScript, the inject won't work properly, and you'll have to use one of these solutions.

Angular, Loop through already created components on the DOM

I'm pretty new to angular, but I have managed to get most of the concepts down. However, I can't seem to figure out how I should go about solving my issue.
I have one component, that has other components as its children. I want to be able to loop through the child components, and add data to them separately, either before they are rendered, or after they are rendered.
The master component is an HTML version of a government form, and I have scattered throughout it a simple component that is supposed to display text from a database relevant to the field it is in.
If I was using something like jQuery, I would just attach an id to each component, and loop through them, adding data if the component id matches the key of the JSON object.
Is there any standard way to do something like this with angular?

You'd be better off "binding" any information you'd like to provide to your child components instead of implementing a vanilla/jQuery solution that involves querying the DOM and then manually manipulating the DOM.
Take a look at property-binding and two-way binding.
Here's a quick example:
<my-child-component [someProperty]="myValue"></my-child-component>
<my-menu-component [menu]="menuData"></my-menu-component>

You probably should rethink the way you are trying to do it, when you start with Angular you need to leave a lot of concept that you learnt in jQuery behind.
We don't manipulate the DOM directly in Angular, we manipulate the data that is bound to the template and that binding is what updates the DOM.
Tom added an answer as I was typing, he is saying what I was going to.

The angular way to achieve what you want is to use one-way data binding. Check out the example in the documentation.
In the example they have a child component in the template html of the app.
<bank-account bankName="RBC" account-id="4747"></bank-account>
You can one-way bind data by referencing a public property on the parent and using the square bracket syntax to indicate one-way binding like so:
<bank-account [bankName]="somePropertyOnTheParent" [account-id]="someOtherPropertyOnTheParent"></bank-account>

Extjs component handlers

How to get component handler in Ext Js?
what are the different ways to get them like
this.lookupReference('ref-name-of-class')
this.lookupReferenceholder('class-name')
this.findParentByType('name-of-xtype')
Ext.ComponentQuery.query('alias-or-id')
Ext.getCmp()
this.up()......
this.down().....
Can anyone list all of them?

Gloabal IDs and Ext.getCmp() is a bad practise. It's slow and colliding global IDs will break everything.
container.getComponent() is also a bad idea. If nesting changes, everything will break.
parentComponent.query() should be used when you want to get multiple child components which are relatively close to the parent. If you want to get a single component, you should use down() method instead. There won't be a big performance hit if the child component you are searching is pretty close to the starting node.
lookupReference() or just lookup() is recommended right now but it will only work within single view or viewController class.

Manipulating data on parent with $event or via $parent in Vue.js

I'm fairly new to Vue.js and I ended up manipulating an array on a parent component using $parent. I'm just wondering if there is some danger in doing it like this:
setTitle(title) {
this.$parent.items[this.index].name = title;
this.editTitle = false;
}
Instead of emitting an event with $emit, and then listening for that on the parent?
Will this burn me in any way in the future?
I' wondering because I've never seen it showed like the first solution in any of the tutorials I've come across.

There is some danger in manipulating a parent through a child, similar to manipulating a child through a parent. The main issue tends to come in separation of responsibility and coupling, if you reuse the code you need to remove or modify any code that manipulates another object in the system.
By emitting an event and letting the parent handle the updated information you can reuse the object in multiple places without modification as any parent that doesn't need to update their items can just ignore the event.
It also makes it harder to maintain the code as someone might see the array get updated but not see the code in the parent object that updates it. In your example it would not be hard to find but if your program became more complex it could take time to find and update or debug.

Most efficient way of "pushing" data to Polymer elements

I have a situation in which I get data over a web socket, and performance is important. From the docs I understand that there are various ways of "pushing" the data I'm receiving to my Polymer elements, but I'm curious which one will be most efficient. So far I've created an element that can be included in a template, where the parent element will observe any changes in the data property and react accordingly. I've also been experimenting with using a Behavior to accomplish the same thing, though instead of needing to include a "data-element" in its template, it could just observe its own data property. I realize I could also use something like iron-signals to "push" the data via an event.
I'm not sure any of these methods are very efficient, since most of the time the changes to the "data" object will only apply to a small subset of all the observers. Another possible solution would be to "observe" a dynamic path, so like data.pathx instead of data.*, which would drastically reduce the number of times the observer callback gets fired, but I haven't come across anything that leads me to think that's possible, since each of my elements won't know if it should observe pathx or pathz until creation.
Like I said, performance is vital, and I feel there is way too much inefficiency if I have a small to medium sized dom-repeat of elements each observing a large data object of another element or individually holding a copy of that data on their own (like I assume a behavior would accomplish?).
I've looked at iron-meta, but I haven't been able to successfully data-bind to it, and from what I can tell from the docs, this data needs to be queried, whereas I need to be notified of changes.

Polymer doesn't really "observe" changes in elements. It just sets a setter for each property, and when it's called the UI is updated. So a dom-repeat template will not observe any change inside an object bound to it.
What could impact performance is unnecessary DOM manipulation, so if just a small subset of the data changes, re assigning all the array to the property is not ideal, and you should use notifyPath with just the sub property path and value that changed. Polymer will only update the DOM nodes affected.
If you have a way of knowing what sub properties changed in your data then you could obtain the object paths that have changed and call notifyPath for each of those and only a small number of DOM nodes will be changed.
Additional note:
If the number of elements in your array change, (added/removed) you should use the Polymer base array manipulation methods to update the property of your Polymer element, so it will change the DOM efficiently.