Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am writing up some code in Javascript/JQuery that involves some confusing DOM operations, or at least they are to me because I'm relatively inexperienced.
I try to help myself by doing a couple of console.log()s, but the thing is if you just log a DOM element you get useless information, mostly it's object Object.
I was wondering what the most usefull generic attributes of a HTML element are so that I could easily follow what the script is doing?
I was wondering what the most usefull generic attributes of a HTML element are so that I could easily follow what the script is doing?
Don't use logging for debugging. Use a debugger for debugging. Even IE (8 and up) has a debugger built in. If you want to know what the code is doing, there's nothing that substitutes for stepping through the code in the debugger and examining your various variables and such as you go.
But answering your specific question, I'd say I'd want to see the DOM element's tagName, className (e.g, class[es]), and id (if any).
I would use chrome when inspecting the console log, the objects actually come through so you can expand and see all of their properties. Keep in mind some of the older browsers, IE8 or 7, do not support console.log and it will throw a javascript error.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
There are many ways to use JavaScript. When I use JavaScript with an anchor, I write code like this and I think this way is right.
Method One
But my co-worker uses JS like this.
Method Two
Is there a coding standard or are both methods correct?
DISCLAIMER: Inline JavaScript is, generally speaking, a bad idea, and 99% of the time you're much better off separating concerns, and using a library, such as jQuery, or whatever similar toolset that your framework of choice recommends.
Nonetheless, to answer your question, if you must use inline JavaScript, I recommend that you omit the "JavaScript:" keyword. It specifies a "pseudo-protocol," and is not necessary for modern browsers to interpret the code. It is a relic from the last decade, and there is a bug with some versions of IE:
"There is one (somewhat obscure) bug with the javascript protocol - in
Internet Explorer*, it will think you are leaving the page when you
click the link. If you are using window.onbeforeunload, then your
navigate-away message will appear at this time. For this reason alone,
we've stopped using the javascript protocol completely so we don't
have this bug show up because we forgot to check for it when we add a
navigate-away message to some page."
When do I need to specify the JavaScript protocol?
https://bytes.com/topic/javascript/answers/504856-javascript-pseudo-protocol-event-handlers
Both the ways are ok but in first way you should use a external JS file. Otherwise it is ok.
For small tasks and events second ways is good.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
As I am learning vanilla JavaScript right now, I don't always know what to ask when searching through JS documentation (mostly on Mozilla MDN). So, I use what I know in jQuery until I get there.
So, what performance or other drawbacks should I be aware of when using jQ to substitute for my lack of full JS understanding while I learn?
These days, clients run fast enough that you don't really need to worry about any performance differences between vanilla JavaScript and jQuery. Thus, it could be said that this is a sort of "premature optimization", so I give you the same answer I always give: Use what you know/what's easier to maintain until you can demonstrate a critical performance bottleneck via a profiler; only then should you figure out how to improve the performance, possibly including switching to vanilla JS.
You should learn to understand how to retrieve elements from the DOM and how javascript relates to HTML. Basically you are altering html-elements and attributes.
http://en.wikipedia.org/wiki/Document_Object_Model
http://www.w3schools.com/js/js_htmldom.asp
https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
So I'm not totally new to web development or anything...reasonably experienced with it actually, to an extent.
But I had only ever used window and document in the past, amongst what I have now learned are many DOM API interfaces.
This is unnerving to me. In my quest to become a truly capable web developer, the extent of the DOM API has so far been the scariest thing I have encountered. It seems very difficult to me to get a real, strong grasp on it.
So I'm wondering, to developers more experienced with this, how did you learn it? Are there any excellent resources in particular, or an order you went in? Which parts of it are important? Which parts could easily be ignored completely?
I mean, even just in document, there are many methods I am totally unfamiliar with.
The following diagram provides an overview of the DOM core interfaces with the most basic attributes and operations. As suggested by Bergi, the most important interfaces are Node, Document and Element. However, when you have to access/manipulate a specific HTML element (e.g. table) you should also look up the interface of such a specific element (e.g.HTMLTableElement) for the availability of useful attributes and operations (e.g. insertRow).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Have written a large system in ColdFusion/Javascript/MySQL. There is lots of Javascript. The few functions which are long are separated into cases. Currently I have all the js in 3 files, depending on the section of the application to which they refer.
Every now and again, some function which tested okay before turns out not to be working (I might have changed something elsewhere to cause that problem, without realizing I had to retest).
Okay, I deserve that, but when one js function in the file stops working, sometimes others do as well. So unexpectedly something I was counting on to validate things, or prevent a submit in the presence of errors does not work.
I've thought of breaking up the js so that any javascript function which is used by just one program will be resident there, and I would use the files with several js functions only for those that several programs have to access. That would insulate my functions somewhat from problems occurring elsewhere.
Is this approach recommended? Could someone offer good reasons for or against it? Or is there a way to "firewall" my functions so that problems with one do not spill over into another?
I'm feeling that the js is a weak link in my system -- that I can't trust it; yet I need it, so I have to find a way to make things more stable. Any and all suggestions to help would be much appreciated.
The suggestion "get better at Javascript" has already occurred to me. I am trying. Meanwhile, my needs are not very demanding. All my functions do simple things and are written in a pretty straightforward way. Yet I am having all this trouble.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm coming from statically typed languages like C++ where there are tools (the compiler for one) that will remind me if I forget something obvious while refactoring. For example, if I change the number of arguments to a function but I forget to change all the calls to it. But it seems really easy to make this type of mistake in javascript. How do you avoid problems like this when refactoring javascript?
just like you do in c++/java. By writing tests.
Unit tests are the best. If you code is MVC, then you can certainly have unit tests with little effort, at least for the model layer. The benefit is you get feedback immediately. Check out QUnit
Functional tests via Selenium or equivalent are good too. They will find problems, but not immediately.
Only thing like that I can think of is: JSLint (http://jslint.com/)