通过对象方法链处理ajax成功回调的干净方法是什么？

Question

So, I'm trying to improve my javascript skills and get into using objects more (and correctly), so please bear with me, here.

So, take this example: http://jsfiddle.net/rootyb/mhYbw/

Here, I have a separate method for each of the following:

• Loading the ajax data
• Using the loaded ajax data

Obviously, I have to wait until the load is completed before I use the data, so I'm accessing it as a callback.

As I have it now, it works. I don't like adding the initData callback directly into the loadData method, though. What if I want to load data and do something to it before I use it? What if I have more methods to run when processing the data? Chaining this way would get unreadable pretty quickly, IMO.

What's a better, more modular way of doing this?

I'd prefer something that doesn't rely on jQuery (if there even is a magical jQuery way), for the sake of learning.

(Also, I'm sure I'm doing some other things horribly in this example. Please feel free to point out other mistakes I'm making, too. I'm going through Douglas Crockford's Javascript - The Good Parts, and even for a rank amateur, it's made a lot of sense, but I still haven't wrapped my head around it all)

Thanks!

Answer 1

I don't see a lot that should be different. I made an updated version of the fiddle here . A few points I have changed though:

• Use the var keyword for local variables eg, self .
• Don't add a temporary state as an object's state eg, ajaxData , since you are likely to use it only once.
• Encapsulate as much as possible: Instead of calling loadData with the object ajaxURL , let the object decide from which URL it should load its data.

One last remark: Don't try to meet requirements you don't have yet, even if they might come up in the future (I'm referring to your "What if...?" questions). If you try, you will most likely find out that you either don't need that functionality, or the requirements are slightly different from what you expected them to be in the past. If you have a new requirement, you can always refactor your model to meet them. So, design for change, but not for potential change.