To set the html of elements on my site, I use mostly
$('elementId').innerHTML = "<p>text</p>";
Looking through the mootools docs, I found this example given:
$('myElement').set('html', '<div></div><p></p>');
Is there any difference between these? Should I go through and change .innerHTML to the mootools method, or doesn't it make a difference?
the reason why the first one works is because - as it stands - a $ selector (document.id) in mootools returns the actual element. this - in normal browsers - is identical to document.getElementById() and the element object exposes any and all of its attributes/properties for you to edit.
the problems with NOT using .set are:
when mootools 2.0 aka MILK gets released, it won't work as it will be wrapped like jQuery and the selector won't return the object (mootools is becoming AMD hence it won't modify native Types - Element, Array, Number, String, Function(maybe!) - prototypes).
you cannot chain this. with set you can: $('someid').set("html", "loading...").highlight();, for example.
set is overloaded - it can set either a single property or multiples by means of passing an object. eg, element.set({html: "hello", href: "#", events: boundObj});
look at https://github.com/mootools/mootools-core/blob/master/Source/Element/Element.js#L936-942 - you can pass an array as an argument and it will join it for you, this makes it easy to work with multi-line strings and ensures performance in IE
edit: the BBT fan has kind of opened a separate topic: should the framework try to block you / prevent you from doing things that break the browser?
if you want to, you can add disallowed elements by changing that setter Element.Properties.html.set = function() { var tag = this.get("tag"); ... check tag }; - isn't mootools great?
mootools - by default - will NOT try to prevent you from doing stupid shit [tm] - that's your responsibility :) try setting height on an element to a negative value in IE, for example. should the Fx class prevent you from doing that? No. Should the setter prevent you? No. The footprint of constant checks to see if you are not breaking means it will slow everything down in performance-critical cases like animations.
Related
I've tried to google my question but it makes me even more confused. My question is:
Here's the jQuery code:
$(document).ready(function() {
$(window).resize(function() {
if ($(this).width() < 200) {
$("p").css("color", "red");
} else {
$("p").css("color", "green");
}
});
}
Why do we write (this) and not ("this") ?
How do I know if (document) and (window) should be written with " " - and why's that?
Maybe you could link me somewhere that explains my issue. My code apparently works either way, I'm just curious about the why.
In JavaScript namespace, this is reserved [source].
The JavaScript object literal this refers to the inherited object from the present state in the current execution.
Another example of this we can see is when we are looping through an array and the object this would symbolize the current array object. You may, for example, see this.title, or this.description if we were iterating through a database array of blog posts.
this in jQuery refers to the inherited object. When we add the quotation marks, and it becomes a string, such as "this". This makes jQuery parse it as a DOM selector.
Then we are now looking for the HTML DOM selector <this>, which to my knowledge, does not actually exist in the accepted HTML syntax standards.
As otherwise stated, the concept of this will become tricky when you are working in other JavaScript environments, such as React or Angular. Within the context of a functional component, this becomes the state, such as handling user sessions.
The component that I have testing renders something this:
<div>Text<span>span text</span></div>
As it turns out for testing the only reliable text that I have is the 'span text' but I want to get the 'Text' part of the <div>. Using Jest and react-testing-library I can
await screen.findByText(spanText)
This returns an HTMLElement but it seems limited as I don't have any of the context around the element. For example HTML methods like parentNode and previousSibling return null or undefined. Ideally I would like to get the text content of the parent <div>. Any idea how I can do this with either Jest or react-testing-library?
A good solution for this is the closest function.
In description of closest function is written: Returns the first (starting at element) including ancestor that matches selectors, and null otherwise.
The solution would look like this:
screen.getByText("span text").closest("div")
Admittedly, Testing Library doesn't communicate clearly how to do this. It includes an eslint rule no-direct-node-access that says "Avoid direct Node access. Prefer using the methods from Testing Library". This gives the impression that TL exposes a method for a situation like this, but at the moment it does not.
It could be you don't want to use .closest(), either because your project enforces that eslint rule, or because it is not always a reliable selector. I've found two alternative ways to tackle a situation like you describe.
within():
If your element is inside another element that is selectable by a Testing Library method (like a footer or an element with unique text), you can use within() like:
within(screen.getByRole('footer')).getByText('Text');
find() within the element with a custom function:
screen.getAllByText('Text').find(div => div.innerHTML.includes('span text'));
Doesn't look the prettiest, but you can pass any JS function you want so it's very flexible and controllable.
Ps. if you use my second option depending on your TypeScript config you may need to make an undefined check before asserting on the element with Testing Library's expect(...).toBeDefined().
But I have used HTML methods a lot and there was no problem yet. What was your problem with HTML methods?
You can try this code.
const spanElement = screen.getElementByText('span text');
const parentDiv = spanElement.parentElement as HTMLElement;
within(parentDiv).getElementByText('...');
There are many examples of doing this in axml, but I would like to have a complete binding using code behind. To be honest, I would like to have NO axml, but seems like creating all the controls programmatically is a nightmare.
I first tried the suggestions at:
MvxListView create binding for template layout from code
I have my list binding from code-behind, and I get six rows (so source binding is working); but the cells itself does not bind.
Then at the following url:
Odd issue with MvvmCross, MvxListViewItem on Android
Stuart has the following comment: Have looked through. In this case, I don't think you want to use DelayBind. DelayBind is used to delay the binding action until next time the DataContext is set. In Android's MvxAdapter/MvxListItemView case, the DataContext is passed in the ctor - so DataContext isn't set again until the cell is reused. (This is different to iOS MvxTableDataSource).
So in essence, the only example I see shows DelayBind, which shouldn't work.
Can someone please show me some examples... thanks in advance.
Added reply to Comments:
Cheesebaron, first of all, a huge thank you and respect for all your contributions;
Now, why not use axml? Well, as programmers, we all have our own preferences and way of doing stuff - I guess I am old school where we didn't have any gui designer (not really true).
Real reasons:
Common Style: I have a setup where Core has all the style details, including what all the colors would be. My idea is, each platform would get the style details from core and update accordingly. It's easy for me to create controls with the correct style this way.
Copy-Paste across platform (which then I can even have as linked files if I wanted). For example, I have a login screen with web-like verification, where a red error text appears under a control; overall on that screen I have around 10 items that needs binding. I have already got iOS version working - so starting on Droid, I copied the whole binding section from ios, and it worked perfectly. So, the whole binding, I can make it same across all platform... Any possible error in my way will stop at building, which I think is a major advantage over axml binding. Even the control creation is extremely similar, where I have helpers with same method name.
Ofcourse I understand all the additional layout that has to be handled; to be honest, it's not that bad if one really think it through; I have created a StackPanel for Droid which is based on WP - that internally handles all the layouts for child views; so for LinearLayout, all I do is setup some custom parameters, and let my panel deal with it. Relative is a different story; so far, I have only one screen that's relative, and I can even make it Linear to reduce my additional layout code.
So, from my humble point of view, for my style, code-behind creation allows me to completely copy all my bindings (I do have some custom binding factories to allow that), copy all my control create lines; then only adding those controls to the view is the only part that is different (then again, droid and WP are almost identical). So there is no way I can miss something on one platform and all are forced to be the same. It also allows me to change all the styles for every platform just by changing the core. Finally, any binding error is detected during compile - and I love that.
My original question wasn't about NOT using axml... it was on how to use MvxListView where all the binding is done in code-behind; as I have explained, I got the list binding, but not the item/cell binding working.
Thanks again in advance.
Here is part of my LoginScreen from droid; I think it's acceptable amount of code for being without axml file.
//======================================================================================================
// create and add all controls
//======================================================================================================
var usernameEntry = ControlHelper.GetUITextFieldCustom(this, "Username.", maxLength: 20);
var usernameError = AddErrorLabel<UserAuthorization, string>(vm => ViewModel.Authorization.Username);
var passwordEntry = ControlHelper.GetUITextFieldCustom(this, "Password.", maxLength: 40, secureTextEntry: true);
var passwordError = AddErrorLabel<UserAuthorization, string>(vm => ViewModel.Authorization.Password);
var loginButton = ControlHelper.GetUIButtonMain(this);
var rememberMe = new UISwitch(this);
var joinLink = ControlHelper.GetUIButtonHyperLink(this, textAlignment: UITextAlignment.Center);
var copyRightText = ControlHelper.GetUILabel(this, textAlignment: UITextAlignment.Center);
var copyRightSite = ControlHelper.GetUIButtonHyperLink(this, textAlignment: UITextAlignment.Center);
var layout = new StackPanel(this, Orientation.Vertical)
{
Spacing = 15,
SubViews = new View[]
{
ControlHelper.GetUIImageView(this, Resource.Drawable.logo),
usernameEntry,
usernameError,
passwordEntry,
passwordError,
loginButton,
rememberMe,
joinLink,
ControlHelper.GetSpacer(this, ViewGroup.LayoutParams.MatchParent, weight: 2),
copyRightText,
copyRightSite
}
};
I just came across a similar situation myself using Mvx4.
The first link you mentioned had it almost correct AND when you combine it from Staurts comment in the second link and just remove the surrounding DelayBind call, everything should work out ok -
public class CustomListItemView
: MvxListItemView
{
public MvxListItemView(Context context,
IMvxLayoutInflater layoutInflater,
object dataContext,
int templateId)
: base(context, layoutInflater, dataContext, templateId)
{
var control = this.FindViewById<TextView>(Resource.Id.list_complex_title);
var set = this.CreateBindingSet<CustomListViewItem, YourThing>();
set.Bind(control).To(vm => vm.Title);
set.Apply();
}
}
p.s. I have asked for an Edit to the original link to help others.
Chrome 24 has a new way of outputting objects in console.log().
For example, console.log($("p")); on this jsFiddle example outputs this insanity:
▼[<p>, <p>, <p>, prevObject: jQuery.fn.jQuery.init[1], context: #document, selector: "p"]
► 0: <p>
► 1: <p>
► 2: <p>
► context: #document
length: 3
► prevObject: jQuery.fn.jQuery.init[1]
selector: "p"
► __proto__: Object[0]
I can see that it puts the collection of DOM elements at the beginning. But if you try to expand even a simple <p> tag that is mostly empty, it throws up all over you:
▼ 0: <p>
accessKey: ""
align: ""
► attributes: NamedNodeMap
...
[stopping here for sanity's sake]
So how do I use all this information? My first instinct is to tame it down to how it used to look, but on second thought, there really is a lot of info in there that I might want to have access to. But I'm having a hard time understanding what I'm looking at. Much of it looks like jQuery values. Is this a list of every jQuery value that the object has (or doesn't have)?
Then there's the whole issue of the ► context: thing and the ► __proto__: thing. Once you start drilling down in __proto__ you will never stop. I think it goes infinitely down!
How can I begin to learn how to use this new output?
EDIT:
I actually just realized that I'm still using Chrome 23, this isn't something that was introduced in 24. Someone in this thread said it was a Chrome 24 issue, but maybe it's new in 23? At any rate, I only just recently started noticing this on jQuery objects.
EDIT 2: If you're just looking for how to log the old way, try this: (hat tip)
console.log.apply(console, $("div"));
In your demo fiddle, you are logging NodeLists or HTMLCollections. Each of the elements within a NodeList is represented as a numeric index 0, 1, 2, etc. 0 being the first in the NodeList if any elements exist in it.
When you expand the Elements you see all available properties of an HTML Element as defined in DOM Core 3 specification. Refer here for more information about this http://domenlightenment.com/#3.2 and for a list of all properties and their purposes go here: https://developer.mozilla.org/en-US/docs/DOM/element. None of this is new in Chrome.
What is new in the latest Chrome version is the top level logged object, so if you just opened the console and typed:
console.log(window)
Which for me when I just did it logged a preview of what the expanded window object it provides when logging it. So for example, you should see something like:
Window {is_minor: 5, bmi_ie6: false, careers_adselector: "div.hireme, div#hireme"...}
Other NodeLists properties listed below the Elements of the list:
context - the context of the selection - http://domenlightenment.com/#4.4
length - the number of Elements in the HTMLCollection
selector - the selector used to select the Element or NodeList
__proto__ - An Object's __proto__ property references the same object as its internal [[Prototype]] (often referred to as "the prototype"), which may be an object or null (in the case of Object.prototype.__proto__). For more info on this refer to: https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Object/proto
I modified the fiddle slightly and should show the preview of the objects when you view the console http://jsfiddle.net/jaredwilli/H3YWq/2/
You can't really get rid of any of these things either, they're a part of the DOM and will exist always otherwise the NodeType of what you're looking at will be something other than an ElementNode.
I'm just as annoyed as you are with this change. I know this isn't ideal, but it will hopefully help you a little bit.
console.log($('p')[0]);
You may have seen that solution before, and then found it didn't work if you were in a loop for instance:
$('p').each(function(){
console.log($(this)[0]);
});
That doesn't end up giving you the result you were used to either, so I had to use ['context'] instead of [0] like this:
$('p').each(function(){
console.log($(this)['context']);
});
Again, I'm looking for a better solution myself, but I thought I'd share with you what I've found.
You want first element so use [0]
As another option, check out Firebug in Firefox. I know, I love chrome too and use it every day, but Firebug is a great plugin and I've never had an issue with it.
var parent = el.getParent();
parent.getElement('div[class=test]'); // return array
var parent1 = el.parentNode;
parent1.getElement('div[class=test]'); // error getElement is not a function
It seems parent1 doesn't have all element methods of MooTools, how to extend all element method of parent1, like in page
Note: I have to use parentNode.
parent.getElement('div[class=test]');
should really be
parent.getElement("div.test");
there's a substantial difference going to element.getParent() and element.parentNode - it boils down to Element prototype, which cannot be extended in old versions of IE.
mootools works around that by saving a reference to the methods directly on the elements instead as properties.
hence if you do element.getParent() and that returns an element, this will extend it to have all the prototypes. element.parentNode returns a simple element object, which will work in browsers where the Element.prototype is inherited correctly.
you can make the second method work in IE by doing:
var parent1 = el.parentNode;
$(parent1).getElement("div.test");
Subsequent references to parent1 do not need the $ (or document.id) as the element will already have been extended.
so to summarize the answer:
to make an element extended, you need to run it through a selector.
var parent = el.parentNode;
$(parent); // this extends it.
parent.getElements("div.test").something()
Both ways work just fine on an element, proof: http://jsfiddle.net/SuJn6/
I assume what you're doing wrong is your el is actually an Element Collection, not a single element. In which case you need to loop your first array, and only then use parentNode, example: http://jsfiddle.net/35Fxf/
Pro-tip: name your variable carefully, el and els - all makes a huge difference.