Javascript Hell

[Freaki Li Cuatre]

As I have posted in the Business/Contracts forum, I've inherited a real mess of a project.

While I can get to work on back end and server side code, the javascript is a god awful mess and I don't even know where to start.

My predecessor decided to use AngularJS & all the control validation code is a horrible mess - boolean variables everywere, convoluted if statements etc.

As a general moan about javascript - even in well implemented projects where people have followed the things we consider to be best practices in software design I always find it ironic that there is such a pile of cack on the client side. I use as little as possible - I quite like JQuery and I like the unobtrusive validation you get with MVC. But here, JQuery = BAD because it performs logic based on IDs and classnames (I argue that I try to use a rules based approach but it doesn't wash). Either way, you're plugging into a tried and tested framework and you're not having to roll too much of your own.

I'm thinking that the problem we have here is that none of the javascript has been written as object oriented code. It's completely procedural - and I have to confess that I don't know how to go about OO in the Javascript world even though it's second nature in C++/C# etc.

The first thing I'd like to do is abstract out all the nasty low level $Ajax calls. There are 26 of them in all - as somebody who likes to adhere to DRY principles, that's 25 too many. What approach would you take to dealing with this? I ask as a novice from a javascript OO perspective so any advice would be more than welcome.

[woohoo]

The first thing I'd like to do is abstract out all the nasty low level $Ajax calls. There are 26 of them in all - as somebody who likes to adhere to DRY principles, that's 25 too many. What approach would you take to dealing with this? I ask as a novice from a javascript OO perspective so any advice would be more than welcome.

I read your post in the business section, think you asked after one of my comments if I had worked at your clients before. So I might learn a few things from some of the answers to your question.

Anyway, my question for you is, can you abstract the 26 calls further? I'm looking at some of my own code at the moment and I have about 8 ajax calls. They are in functions that are well named and they all do things slightly different. For example in one function I've increased the timeout, on others I retrieve data from the page differently and on others if the call is successful I manipulate the page for example disabling/enabling buttons. So if a person hasn't done x they cant do y. Some calls retrieve a partial view others may populate a drop down with values.

So I guess I'm saying that for me $.ajax is abstracted enough. But looking forward to other answers.

[Freaki Li Cuatre]

So I guess I'm saying that for me $.ajax is abstracted enough. But looking forward to other answers.

I'm just thinking of DRY principles really. Instinctively it seems wrong to have it appear in 25 different places.

Since the error callback is the same everywhere in my app that's at least one bit that doesn't need repeating. I wouldn't put it in a wrapper just for that though....

Could there also be scope issues if $ajax is appearing everywhere in different js files? i.e. it could, through some bizarre set of circumstances, be out of scope in one of these files. If it's just in one place that'll be much easier to handle. I doubt this would ever occur though - I'm just trying to justify why I don't like it.

[woohoo]

I'm just thinking of DRY principles really. Instinctively it seems wrong to have it appear in 25 different places.

Could there also be scope issues if $ajax is appearing everywhere in different js files? i.e. it could, through some bizarre set of circumstances, be out of scope in one of these files. If it's just in one place that'll be much easier to handle. I doubt this would ever occur though - I'm just trying to justify why I don't like it.

I understand what you mean about DRY, for example I often have a pattern where I display a list of items and the user can delete the item using an ajax call and remove the item from the list on the page. So that's in a utility class because it makes sense, url is from the link, standard confirm popup and remove a row using an id attached to the tr.

But I'm wondering if your 26 ajax calls are specific to a complex page(s) and won't be so easy to abstract without making a function which pretty much mirrors $.ajax.

Regarding out of scope, not sure it depends on how these guys have structured their js. Often the jquery libraries are bundled together and added to a layout view and accessible to views that use the layout. So not usually a problem. I've not found this to be a problem others may have different experience than me.

If your worried about conflicts with other libraries then perhaps go down the route of using namespaces.

I usually add an init: function and this is where I attach functions to events and do my page setup. It seems clean to me because In a glance I can see what's going on with the page. But I'm not a javascript guru so could be better ways to structure your code.