I have an issue where input is being doubled, tripled, quadrupled, etc. on user input after changing a select dropdown multiple times. Here's a small video showing my dilemma and posing the question: http://screencast.com/t/7Gb01nGe787p
Essentially the question is how to debug properly given circumstances like this?
I think how you debug depends heavily on how your code is structured.
If you are using widgets(jquery UI stuff, plugins, external libraries etc) you can always search around and see if its a known bug/issue. Aside from that, checking configurations(I've been burned by config's not being correct several times) can be helpful. Also check for conflicting code, such as events you may have defined that could interfere with the widgets behavior. Manipulating objects in the webkit console is particularly useful for this, since you can more easily find out in what cases your code will work, and in what cases it will not, without necessarily having to rely on manipulating the UI.
If you are not using something other people wrote, then debugging is a little easier in my opinion. For me, it really comes down to narrowing the scope of where I am looking. If you have any events related to your issue(onKeyUp or something), log it. Console.log can go a long way, especially when dealing with the state of UI, and so can breakpoints. I'm not sure if this is necessarily the best way to do it, but I find it to be very useful in the right situation.
If you are really stuck, you can always get drastic and start removing pieces of your code. May not sound very nice, but if you are really stuck and cannot seem to find what section of code is being problematic it will at least give you an indicator of where to look. Again, not the prettiest solution, but it's saved me a lot of headaches on more than one occaision.
Hope this helps.
Related
I work for a small company that isn't flexible in making changes on using a heavy themed webpage on Wordpress for their own reasons. They are also using a load of plugins, and it takes more than 10 seconds to load. So, I thought I should give it a try and check the generated homepage source code, after I ran the analysis that tells me that js is just a disaster.
The theme they had chosen was Unero, because it works with woocommerce I suppose. The website is a small e-shop along with a blog, nothing too fancy really, we use yoast SEO too, but that might be irrelevant.
I realized that there is a load of js scripts running here and there.
I read that you can set everything run with async set true.
A also read that this can cause things to break between scripts, due to undefined variables and other problems I suppose. Please note that I am kinda new to js technologies and I might not know what I really should be asking, or searching for. I do my best to explain what I need to happen though.
Is there a way you can override ( or overload, what is the term
here?)some js on footer, after being defined on their positon
(in HEAD and in BODY),setting it to async mode, by using a snippet
on footer? Will this actually work?
I do not want to involve any plugin general solutions, because I am
afraid they will break stuff as mentioned above. Correct me if I am
wrong and please suggest me something. Except if the solution IS to make a custom plugin, where I will have full control I guess.
I am open on ANY suggestions, as long as it won't break the site.
I am asking here and not on Wordpress Developement or any other Stack Exchange forum, because I am looking for a solution done by hand, along with an explaination why it will work. I am a code by hand guy really, and I am not afraid to dive deeper on something, if things are gonna be done right.
Is there a way you can override ( or overload, what is the term
here?)some js on footer, after being defined on their positon (in HEAD
and in BODY),setting it to async mode, by using a snippet on footer?
Will this actually work?
Answer: Yes, its possible but that could also happen with sync code. If plugin A is doing something like $('title').text('Title from A') and then the next plugin does $('title').text('Title from B')then its gonna get overridden, doesn't matter if its sync or async.
I do not want to involve any plugin general solutions, because I am
afraid they will break stuff as mentioned above. Correct me if I am
wrong and please suggest me something.
Answer: I am not sure what you want to do. What is your goal with this site? Do you want to untangle the mess of the plugins? That can be difficult since you have little control over the plugins and their mechanismm.
I am open on ANY suggestions, as long as it won't break the site.
Answer: One way would be to disable them one by one to see cause and effect and try to clean out that way. Another solution would to switch to more simple solution like Shopify and the third to creaate a custom solution that you have more control over.
Its quite an open question, so its kinda of hard to give a concrete answer or solution to your problem.
So I have a fancy GUI in jQuery, which has gotten relatively complex. I would like to write tests for it, e.g. using assert(). However, it seems that writing such tests is difficult because GUIs don't manipulate data or make computations: they are just superficial interfaces to please the user.
So how does one generally write tests for GUIs?
assuming your code is fairly clean (modular and loosely coupled pieces of functionality that work together rather then a few uber functions), the first thing to do is choose a test framework. I recommend jasmine, because it fits the way I like to write tests, but if you are looking for more of an xUnit clone, qunit is also very well made.
If your code is not pulled apart (like 99.99% of javascript in the wild), I would first look at how to make jquery plugins, and extract as much as you can into them. Testing uber-functions that do loads of things is a scary proposition, but when you are talking about a module that does a single thing, testing gets much easier.
Finally, there is a bit of a learning curve with both how to structure complex javascript, and how to test it. Don't give up! Contrary to what some people would have you believe, javascript is very testable nowadays with very solid libraries and there are many people doing it (I just spent all day working on complex functionality, was practicing TDD the entire time, and it never felt clunky or unnatural)
Good luck, and feel free to ask for clarification if something here is unclear :)
EDIT:
By "pull apart" I mean move to a more modular approach rather then gigantic functions. In jQuery, the first step is with plugins, which will take you pretty far. If you are making a javascript "application", where most of your logic is in the front end and the back end is mostly for persistance, I would look at stuff like Backbone.js, which will help manage a very high level of complexity, but is totally overkill if you don't need it.
Going back to extracting plugins, try to find pieces of functionality that are sort of contained. I wrote a quick plugin today to remember the state of checkboxes in a table with paging, where the contents of the table get swapped out programmatically, but if a user checks a box on page one (but doesn't save), goes to page two, then back to page one they should still see that box checked.
If that checkbox code was inline in the paging code, it would make the paging code WAY more complicated. By pulling it into a plugin, it only complicates the paging code a little bit (calling $(table).saveCheckState() when a page unloads, and $(table).loadCheckState() when a new page loads) It also makes the testing very straightforward, all I need is a div with a few checkboxes to test the checkbox code, rather then needing to add more to the paging tests which are already pretty complex.
Not knowing your background or level of experience I would hesitantly recommend reading clean code if you want to learn more about this sort of stuff. Unfortunately is it java oriented rather then javascript, but most of it is universally applicable in any object oriented language (which javascript can be), and is probably the best intro level book into this topic. If you do full stack development (rather then just front end), have at least a working knowledge of java, are a junior/intermediate dev who wants to improve their craft, its one of those books everyone should read. If those things aren't true, it may end up just being confusing, or just not really be much use to you. So take the recommendation with a grain of salt :)
Your answer is in GUI itself - User interface.
GUI's are best tested with people. You should check out http://ux.stackexchange.com which is dedicated entirely to the user experience.
I think this is important, because I'm sure your GUI is to the point where it is solid, as you've done the unit testing on non-graphical elements. Through your own testing you've made it this way - now, you should see how other people interact with it, how they break it, and what they like or don't like about it. Then you make changes and do it all over again.
(Ok, I know this isn't unit testing. But seriously, the options out there for heavy testing of jQuery stuff are not that fun to deal with!)
I was just reading an article about the non-compatibility of some CSS, when it occurred to me that maybe I should be writing all of my CSS in jQuery. Aside from javascript-disabled browsers, which any ajax website isn't going to support anyway, what's the downside?
The benefit, aside from greater browser support, would be the use of variables throughout the (pseudo) css file. I could control a color across borders and backgrounds etc. in a single place. I know this has been done with backend programming, but I'm seriously considering it with front-end. Anyone wanna talk me off the ledge?
The article I was reading is here, if you're interested:
http://www.impressivewebs.com/buggy-css-selectors-cross-browser-jquery/
Javascript-disabled browsers, like you say. More people have Javascript turned off than CSS turned off.
Secondly, I imagine the performance will be worse on the clients-end.
In general, CSS goes at the top. This means that the browser can style the HTML as it loads, rather than waiting for all the HTML to load. With Javascript, unless there are some really fancy tricks which I don't about it, you would need to wait for the HTML to load before you could do your styling, resulting in a FOUC
Also, browsers are also heavily optimised to execute CSS as efficiently as possible.
There are more reasons... plenty more.
Before I get to the reasons I will just say without even giving this any thought whatsoever it sounded like a bad idea. Sure there might be some CSS that is incompatible across browsers but those situations are definitely a minority. Remember CSS is a standard. So the majority of it is going to be implemented across the board.
But for the more logical reasons:
Performance would be a major issue to consider as now your clients browsers are going to have a lot more to process. Plus js is linear so everything would have to wait for the prior function to finish, there are some workarounds to this, but for the most part this could be a big issue.
What you can accomplish in a few lines of css could be several more with js. And that would be per page since you couldn't really reuse a lot of it.
What happens when you leave your place and a new developer comes in and wants to change styles across all pages. Guess what he's screwed?
I can't even seeing this saving you anytime because with css you can write in one place and apply everywhere. With your js solution you would have exponentially more code to maintain.
The other reason you mentioned with js turned off. Sure your ajax calls aren't going to work like you mentioned so there will be some problems but at least they will be able to see what your site looks like without just seeing a bunch of text everywhere.
I could go on but I think you get the point this is not a good idea by any means.
Of course, this is just my opinion so take it for whatever it is worth. But I think you would seriously regret this decision.
EDIT: Sorry for the novel. One last thing though, the article you referenced was about CSS selectors and not overall css.
Is it good or okay to have several frameworks in a project, or is it bad because it gets cluttered (= a mess), and the loading times maybe get's longer. Does some 100 K matter really? Or should you stick with one?
It's generally better to pick one thing and stick with it, for a number of reasons:
Fewer dependencies.
Lower complexity.
Easier to maintain.
Faster loading times.
No likelihood of dependency conflicts (i.e. jQuery can't conflict with your other Javascript framework if you only have one).
Lower debugging times.
It's true that an extra ~50k these days probably isn't going to kill anybody for a personal site or blog. The benefit comes when you scale to larger sizes, and all those extra 50k hits are eating into your bottom line. But even if you're just doing this for a small site, the savings on your sanity from figuring out problems quicker will easily be worth it.
That said, if you just need one part of a specific piece of a Javascript framework, the larger ones are often split into logical chunks, so that you can just take the piece you need rather than the entire framework. Most are rich enough these days that if framework X has a feature you want, but you're using framework Y, you can pretty much just map the source code for that feature directly into framework Y.
If you can load the javascript library from a repository where it would be cached on the first visit, then i don't really see any problem with that.
But, for uniformity sake i will go with one javascript library.
But, if you really have any strong reason to use two, then go ahead. As far as it is cached the first time.
Just adding something to John's words, one could choose, for example, JQuery, which allows you to use it without clashing with other libraries. I remember that once, I had troubles while trying prototype and mootools because I wanted some things from the former and some other from the latter, but it was long ago and maybe it was solved.
Somehow, I've found that it's easier to maintain a single library and there're a few real differences between them. It related more to the way each one approaches to map documents and apply things to their elements, which causes differences in response time, but the goal happens to be the same.
Good luck with your choice :)
PS. If you gzip and fix etags in the stuff you offer in your webapps, the difference between loading one or two js frameworks is not reeeeaaally important -unless you're in facebook, meebo or so!-. I've found that the yahoo! recommendations are helpful.
http://developer.yahoo.com/performance/rules.html
I wouldn't run two frameworks unless there was really no alternative. They often aren't written to play well with others; there are lots of potential ways they can cause unwanted interactions.
For example with jQuery, a lot depends on the user-data key identifiers the library adds as attributes to element nodes. If you start messing with the structure of the document by cloning, adding/removing and so on from another framework (or even just plain DOM methods) then those identifiers aren't as unique as jQuery expects; it can easily get confused and end up failing to call event handlers, or tripping on errors. This sort of thing isn't fun to debug.
I have extensively used Prototype before and it helped us add considerable interactivity to our web applications. However we are looking at making the move to use jQuery in order to standardize on something better supported in Visual Studio.
I understand that we can use the jQuery.noConflict to run it alongside Prototype, but we would like to avoid having users need to download both libraries to use our website.
So, is there a good resource that can help us move old scripts from Prototype to jQuery?
I can't really help you too much with your question, other than to say that I haven't heard of any such tool, and that I'd be really surprised if one actually existed.
While I think jQuery is a great library, and that you're right to be wanting to only use one library, just remember that the cost of you changing over all your scripts is going to be many many hours of work. The cost of your users downloading an extra 30kb of scripts is going to be roughly 0.3 seconds. Perhaps try to slowly phase out Prototype and only refactor your existing pages when a) you have to, or b) if you've got nothing better to do.
Falkayn,
There is no automated process available for conversion of JavaScipt code written against one JS library to another one. Moreover there cannot be one. Different libraries implement different proramming models as well as they arrange their APIs in different manner.
So, before you have found a solution to your problem now ask yourself a question: Am I going to convert my jQuery code once another even "cooler" "X-type" JavaScript library became available?
If your answer is no, take your time and convert the code manually no mater how long will it take. In case you answer "yes" don't convert the code at all.
So it goes.
Thanks guys for your input. I was looking for more of a syntax comparison than anything automated, but nickf makes a good point in that the real cost need not be too great. We only used Prototype on a few pages that really needed a high level of interactivity, so as long as mind out Ps and Qs it should not hurt to use jQuery everywhere else.