How to dynamically access children of a slot - javascript

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.

Related

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.

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.

Using JQuery plugins that transform the DOM in React Components?

Some JQuery plugins don't just add behavior to DOM nodes, but change them. For example, Bootstrap Switch turns
<input type="checkbox" name="my-checkbox" checked>
into something like
<div class="bootstrap-switch bootstrap-switch-wrapper bootstrap-switch-on bootstrap-switch-large bootstrap-switch-animate">
<div class="bootstrap-switch-container">
<span class="bootstrap-switch-handle-on bootstrap-switch-primary">ON</span>
<label class="bootstrap-switch-label"> </label>
<span class="bootstrap-switch-handle-off bootstrap-switch-default">OFF</span>
<input type="checkbox" name="download-version" checked="" data-size="large" data-on-text="3" data-off-text="2.0.1">
</div>
</div>
with
$("[name='my-checkbox']").bootstrapSwitch();
Which doesn't jive with React:
Uncaught Error: Invariant Violation: findComponentRoot(..., .0): Unable to find
element. This probably means the DOM was unexpectedly mutated (e.g., by the
browser), usually due to forgetting a <tbody> when using tables or nesting <p> or
<a> tags. ...<omitted>...`.
Is there a recommended technique for incorporating these plugins into React components? Or do they fundamentally break the assumptions of React and cannot work with it?
No, react will react (haha) badly to anything that modifies its own component dom structure outside of react. This is something you don't ever want to do. The recommended solution would be to replicate the functionality of whatever you're trying to do with a jquery or similar plugin, in react.
Having said that, there is a reasonable way to do this for specific instances where you just can't do without it, but it essentially means wrapping some non-react dom inside react.
Example:
var Example = React.createClass({
componentDidMount: function() {
var $checkboxContainer = $(this.refs.checkboxContainer.getDOMNode());
var $checkbox = $('<input />').prop('type', 'checkbox');
$checkboxContainer.append($checkbox);
$checkbox.bootstrapSwitch({});
},
render: function() {
return (
<div>
<div ref="checkboxContainer"></div>
</div>
)
}
});
Now of course you are rendering a component with a nested div. The nested when mounted to the dom for the first time that nested div will get a checkbox appended to it by jquery, which will then also execute our jquery plugin on it.
This particular example component has little point to it, however you can see how this might integrate into a more complex component while still allowing you to re-render and react to state changes etc. You just lose the ability to directly react to events/modify things inside of the checkbox in question which as far as react is concerned, doesn't exist.
Now with the above example if you were to have some react logic to add/remove the nested div, you'd have to have the same logic around that div being inserted be responsible for re-inserting the checkbox and re-initializing it with the jquery plugin. However because react only modifies the dom when needed, this inserted dom content wont be removed unless you do something that modifies the container div in a way that causes it to be removed/re-rendered to the dom. This means you can still access all of the events within react for that container div etc.
You could also make use of the componentDidMount function in react to bind events or callbacks to specific interactions on the checkbox itself. Just make sure to unbind them correctly in componentWillUnmount or wherever it makes sense to do so in the component lifecycle in your specific case.
In this great ryanflorence's tutorial you'll get an idea on how to do this:
Wrapping DOM Libs
Methodology
DOM libs usually manipulate the DOM
React tries to re-render and finds
a different DOM than it had last time and freaks out
We hide the DOM
manipulation from React by breaking the rendering tree and then
reconnecting around the DOM the lib manipulates.
Consumers of our
component can stay in React-land.
Sure, there is such a technique. We're doing these things all the time.
You create React component to wrap jQuery plugin.
Inside of your render(), you return an empty <div ref="placeholder" />
In your componentDidMount method, you retrieve this element by its ref, and initialize your jQuery plugin there.
In your componentWillUnmount, you clean it up. Calling 'destroy', or anything else required to avoid memory leaks.
That's it. Fortunately, it's completely safe to modify DOM in this way in React.
If you want this plugin to react on props changes, things get a bit more tricky. You need to override other lifecycle methods, like componentWillReceiveProps, check whenever props actually changed, and call corresponding plugin methods. I can explain in more details, if you will have specific questions, overall topic is too broad for the comment.
This is more of a philosophical question
React was created to optimize DOM manipulations and has a lot of wiring behind the scenes to do so when a component's state changes via setState
Doing so will cause said wiring to traverse its virtual DOM to find the nodes that need to be updated
If you must use React, whether to try to keep a level of consistency in your coding, your best bet is to apply the JQuery DOM manipulation inside the componentDidMount like so...
componentDidMount(){
this.node = $("#"+this.props.id); // Keep a reference to the node
this.chart = this.node.easyPieChart(); // Apply JQuery transformation and keep a reference
this.percentTitle = this.chart.find(".percent"); // Keep a reference to the title
}
Having done so, on whatever your "refresh" method is, do NOT make any calls to setState, instead, call whatever update method your JQuery component may have, like so...
componentWillMount(){
this.interval = setInterval(this._doRefresh.bind(this), 1500);
}
_doRefresh( percentage ){
// Note how setState is NOT being called here
percentage = percentage || Math.floor (Math.random() * 100) // simulate since we're not getting it yet
this.chart.data('easyPieChart').update(percentage); // call easyPieChart's update
this.percentTitle.text(percentage);
}
At this point, if you're asking why use React at all, well, in my case, this component is an item in a list of other React components and was used to maintain consistency throughout the application... You may have a similar dilemma
If, unlike me, you are unlucky enough that your component doesn't have an update method, and you can't make one, it might be time to rethink the approach altogether

How can I handle a Knockout.js mapper bastard-child?

I'm using the mapper plugin on Knockout.js to handle JSON coming from a server. I've set up a parent and a child, however some children don't have parents. These stray children need a handler to put them in a new parent or model like "foster parent" and have a way to access the foster parent and iterate with a "foreach" in a separate list.
Here's a code sample of what I have so far: http://pastie.org/3708368
Where would the handler go for foster parenting? Or can I just prepend the parents with a special foster parent?
The basic use case is the children are unassigned tasks (to give context).
Thanks for the input!
I was able to draw a lot on this advanced example: http://jsfiddle.net/rniemeyer/UdXr4/
It simulates a seating chart and uses the author's custom plugin, Knockout-sortable. I highly recommend it. After examining the example, I realized there was no need to use a mapper but instead I could define a view that accessed a specific collection.
Props to the author, that's a lot of helpful and useful work.
Update
There's a much better technique to set properties of children using the create during mapping. See this GitHub issue: https://github.com/rniemeyer/knockout-sortable/issues/15

Categories