I have a simple list component in Vue2 with the ability to add/delete items. My issue was that when I switched from a regular HTML element to material-ui (https://vuematerial.io/), my input-clearing functionality broke.
This is what it looked like:
With the regular HTML element, I was simply targeting the element by ID (from within the methods of my component script) and assigning it an empty string to clear it, as so:
if (input.value !== '') {
this.items.push({
text: input.value
})
input.value = ''
}
I found the solution, which I'll answer below, but again, my question was: How do I clear the field when using a material-ui element? And the bonus question, which I haven't fully answered for myself: Why did it break?
So, first the "how" to make it work:
I needed to set a "v-model" attribute on my element (I called it "inputField"), and then initialize it to empty within the component's data properties, and THEN in my component methods "addInput" function, I had to set "this.inputField = ''" instead of "input.value = ''".
To illustrate:
So, that works. Here's the result:
Now, that just leaves the question of exactly how this all works, and why the method which worked for a regular HTML failed on ? I'm not sure, and I'd welcome an explanation/education from anyone who can explain!
Vue DevTools for Chrome seems to give a hint:
"Mdclearable" seems intuitively to be related; this property is set to false. Is that something to do with it? I'm not sure.
Learning a bit more about Vue's "v-model" and reactivity was also helpful in solving this.
Again, additional comments welcome to help elucidate what is going on here! And I hope this Q&A will help someone else possibly avoid some frustrations in future.
Related
I try to pass a value to an Zend-Form element. It shall be filled when the formclass is instantiated. Perhaps it is even the wrong idea?
What I gonna do:
I want to give a value to my formclass via my controller addAction:
$form = new PadForm(NULL, $test->UnitPartID);
Here is the constructor of my form class:
public function __construct($name = null, $unitpartid)
Now I thought it must be easy to give the value to an element:
add.phtml
$UnitPartID= $form->get('UnitPartID');
$UnitPartID->setAttribute('class', 'form-control');
$UnitPartID->setAttribute('placeholder', 'UnitPartID');
$UnitPartID->setValue($this->unitpartid);
Unfortunately the form element doesn't get the value.
Where is the error? I think I'm quite close to the solution?? Any help appreciated.
It's a bit of a shame, because it is so easy in the end. But for beginners in Zend, it is sometimes hard to understand, where to do things properly.
So I want to post the solution for others who have the same issues.
In my controller addaction I gave the form field a value, after instantiating the Form class.
$form->get('Formfield')->setValue(some variable);
I had the hole topic, because I was searching for a possibility to do it in the view. There I could give a value of course, but I couldn't fetch a variable. If somebody has still a suggestion for this possibility, please post. I answer my question because I now have one working solution.
My problem seemed easy at first but i got stuck.
I have some containers (divs) in my page with some custom attributes.
<div class="myclass" myattr1="blah" myattr2="text1-text2-text3-text4-"></div>
myattr1 and myattr2 are defined by me.
All divs are visible on page load.
Now, depending on user selection from a list, i want to show only the divs with myattrib1="blah" and hide the rest.
I tried the following code, with no success at all
$('#mySelectID').change(function()
{
var startName = $(this).val();
$(".myclass").not('[myattrib1!="+startName+"]').toggle();
});
The same approach will be used to filter results by attrib2, but there i will use myattrib2|="+startName+" ( i think this is correct - thats why i have the extra - on the end of myattr2="text1-text2-text3-text4-").
Can anyone advice me on how to properly achieve this kind of filtering?
thank you!
You are close, but as you can see form the syntax highlighting, your are not performing string concatenation. +startName+ will be taken literally. Fix the quotes and your fine:
.not('[myattrib1!="' + startName + '"]')
Note that you should be using data-* attributes instead of custom ones.
In several recent answers I see this code given as the way to retrieve the currently selected value of a <select> tag:
el.options[el.selectedIndex].value
Whereas the MDN documentation says that the .value property of an HTMLSelectElement is equivalent ("The value of this form control, that is, of the first selected option.")
el.value
Is there some reason (old broken browsers?) why the longer version seems to be preferred?
To my best knowledge, the .value way has always worked.
There is actually an extra problem with the first one - what happens when the user has not yet selected an option? Then the .selectedIndex is -1, which will make your script crash.
So go with el.value
I have a problem with my firefox extension
I have a XUL popup panel with a hbox for the tag cloud, and a JS code to add divs to this hbox:
<hbox id="tag_base" ondblclick="alert('done')"/>
JS:
var root = document.getElementById('tag_base');
var tag = document.createElement('div');
tag.textContent = 'test';
root.appendChild(tag);
var rect = tag.getBoundingClientRect()
alert(rect.top)
I need to get the dimensions of each added div, however, getBoundingClientRect simply refuses to work.
If I remove alerts, it's always zero.
With alerts the story is different:
The first time the alert is called it returns zero, although the div appears on the screen.
Any subsequent alerts return the correct coordinates.
If I set a breakpoint in Chromebug, everything is reported correctly.
If I do not interupt the execution in any way, and run a loop, only zeroes got returned.
This has got me quite confused.
Calling "boxObject" produces the same results, while "getClientRects[0]" is undefined on the first call.
Any hints on what might be causing this will be greatly appreciated.
Note :
Caution, if you use getBoundingClientRect with an element which has display:none then it will return 0, anywhere in the dom.
Although I can't find any documentation on this seemingly fundamental issue, the problem you noticed is most likely because the layout (aka "reflow") process has not yet run by the moment you ask for the coordinates.
The layout/reflow process takes the page's DOM with any styles the page has and determines the positions and dimensions of the elements and other portions of the page (you could try to read Notes on HTML reflow, although it's not targeted at web developers and probably is a bit outdated).
This reflow process doesn't run synchronously after any change to the DOM, otherwise code like
elt.style.top = "5px";
elt.style.left = "15px";
would update the layout twice, which is inefficient.
On the other hand, asking for elements position/dimension (at least via .offsetTop) is supposed to force layout to return the correct information. This doesn't happen in your case for some reason and I'm not sure why.
Please create a simple testcase demonstrating the problem and file a bug in bugzilla.mozilla.org (CC me - ***********#gmail.com).
My guess is that this is related to XUL layout, which is less robust than HTML; you could try creating the cloud in an HTML doc in an iframe or at least in a <description> using createElementNS to create real HTML elements instead of xul:div you're creating with your current code.
Be sure the DOM is ready. In my case, even when using the getBoundingClientRect function on click events. The binding of the events needed to happen when the DOM is ready.
$(this+"p").slideDown("slow");
$(this)+$("p").slideDown("slow");
$("this+p").slideDown("slow");
does not work.
Yeah, your syntax is bad. You should use the jQuery Sibling function:
$(this).siblings().find("p").slideDown("slow");
The jQuery API site is awesome for looking stuff like this up, I rely on it nearly daily. I'd keep an eye on it.
Next.
$(this).next("p").slideDown("slow")
Make sure that the "p" element is directly adjacent, though. Otherwise you'll want to use nextAll.
jQuery have not seemed to apply this? Possibly the syntax we are trying to use is incorrect.
next() can only select elements with an ID or Class - Not just a naked dom element as expected.
Instead use. > means select first level decends only.
$('body > div').hide();
But this gives the exact same result
$('body').children('div').hide();
But,
Next
$('body + div').hide();
and
Previous
$('body ~ div').hide();
Do not seem to work as expected? But jQuery use it as example for CSS selection...
Possibly there is a complex syntax to achieve this but I could not figure it out...