1

I've had this happen to me three times now and I feel it's time I learned how to avoid this scenario.

Typically, I build the HTML. Once I'm content with the structure and visual design, I start using jQuery to wire up events and other things.

Thing is, sometimes the client wants a small change or even a medium change that requires me to change the HTML, and this causes my javascript code to break because it depends on HTML selectors that no longer exist.

How can I avoid digging myself into this hole every time I create a website? Any articles I should read?

Only Bolivian Here
  • 35,719
  • 63
  • 161
  • 257
  • 1
    How does it different from every other changes in the demands of the client? – gdoron May 24 '12 at 19:04
  • Other changes don't require me to test on many different browsers for the selectors to work. – Only Bolivian Here May 24 '12 at 19:04
  • 5
    Replace `.parent().parent()` with `.closest()`, `.children().children()` with `.find()`, and make your selectors more general, such as instead of doing `div > div > div > a`, do `div a` so that if one of the divs are removed, it still works. – Kevin B May 24 '12 at 19:04
  • I don't understand something: if the selector does no longer exist, why would you keep a JavaScript behavior that's bound to it?! Otherwise, simply use CSS classes (`
    ` and `$('.myBlocks')`).
    – Samy Dindane May 24 '12 at 19:05
  • a specific example would help. as it is, this sounds less like a 'code hole' and more of a 'project management hole' you're digging. – DA. May 24 '12 at 19:30
  • 1
    @DA it would help, but as you can see from my answer, there are general guidelines. Clients always want updates, I'm not sure what you mean by a project management hole. – Ruan Mendes May 24 '12 at 19:36
  • I don't mean anything specific. I can't, really, a the question isn't specific. In general, though, if the client changes are requiring a lot of code changes, then it's maybe not a code issue at all, but rather how the project is being managed in terms of schedules, client expectations, change orders, etc. – DA. May 24 '12 at 19:42
  • @DA. I disagree, the customer is always right. Programmers should write code that is easily modifiable, we can't expect clients to get it right the first time. Design for change, assume the very least you can in your code. – Ruan Mendes Aug 07 '12 at 18:00
  • @JuanMendes Whether clients are always right or not is another debate, but that's not what I was referring to. I saw referring to project management. Yes, one should always build manageable code, for sure. And that's much easier to do with the project requirements are managed equally as well. – DA. Aug 07 '12 at 18:35

1 Answers1

5

Make your selectors less brittle.

  • Don't use a selector by index, next sibling, immediate child, or the like
  • Use classes so even if you have to change the tag name and the element's position in the HTML, the selector will still work
  • Don't use parent() or child() without specifying a selector. Make sure you look for a parent or child with a specific class

Sometimes, depending on the amount of rework, you'll have to update the script. Keep them as decoupled as possible, but there's always some coupling, it's the interface between script and HTML. It's like being able to change an implementation without having to change the interface. Sometimes you need new behavior that needs a new interface.

I think the best way to help you is for you to show a small sample of a change in the HTML that required a change to your jQuery code. We could then show you how to minimize changes to JS as you update the HTML

Ruan Mendes
  • 90,375
  • 31
  • 153
  • 217