3 ms·

Keeping your Javascript clean

13 points by turoczy 14y ago

th5 14y ago
can anyone give some detailed examples on "encapsulating/abstracting away state."
- sktrdie 14y ago
  Yes, some examples for each of the points would be extremely helpful. Interesting points nonetheless.
  - bradhe 14y ago
    Thanks for the suggestion. I'll see about putting some together. Wasn't really sure about including examples as to whether it would be helpful or not...
- bradhe 14y ago
  In writing the article I found I had a tough time putting this one in to words. If you've got experience in writing server-side code, this is already pretty ubiquitous thanks to the "fat model" paradigm. Basically, a given object should manage it's own state and everything else should ask it about it's state. Consider the direction type selector in Google Maps: http://i.imgur.com/5zQcp.png http://i.imgur.com/5zQcp.png. I would create an object that manages all those buttons. The object would keep track of whichever button is selected and would probably emit an event that said "user changed selection." Then the controls that, say, sent a request to the server for a new set of directions would query the object for the current state. Couple of advantages here. 1. It's UI-agnostic. That is, the other controls on the page don't have to care how it's actually rendered at all. 2. It's encapsulated. There's a single way to get the selected direction type. 3. It's much more test friendly. You've essentially abstracted away the DOM for that control. The hard bit about doing this in JavaScript is it's unenforcable in a team environment. What's stopping the other devs from reaching in to the DOM and querying for the selected button? Hope that helps a bit...
jay_kyburz 14y ago
Heads up cloudability. If front end and UI is important may I suggest a different font for the blog. Really hard to read here on windows.
- sktrdie 14y ago
  Seems pretty readable to me. Plus, color contrast is more in the area of making things look good, which is not what the UI does.
  - FrancescoRizzi 14y ago
    Not to be polemic, but I agree that there's something in the current typographic settings that could be improved. I tried to disable the CSS rule from corporate.css::1 on body for font-family (making the font fallback from 'Myriad pro' to the Helvetica family from foundation.css::75) and I think the result is much more readable - although it still has space for improvement in line-height and contrast). HTH
maytc 14y ago
Ironic but your fonts and javascripts are not loading on my chrome
christianreed 14y ago
I've also had issues getting the Cloudability blog through my feed reader in the past.

13 points by turoczy 14y ago

th5 14y ago

can anyone give some detailed examples on "encapsulating/abstracting away state."

sktrdie 14y ago
Yes, some examples for each of the points would be extremely helpful. Interesting points nonetheless.
- bradhe 14y ago
  Thanks for the suggestion. I'll see about putting some together. Wasn't really sure about including examples as to whether it would be helpful or not...
bradhe 14y ago
In writing the article I found I had a tough time putting this one in to words. If you've got experience in writing server-side code, this is already pretty ubiquitous thanks to the "fat model" paradigm. Basically, a given object should manage it's own state and everything else should ask it about it's state. Consider the direction type selector in Google Maps: http://i.imgur.com/5zQcp.png http://i.imgur.com/5zQcp.png. I would create an object that manages all those buttons. The object would keep track of whichever button is selected and would probably emit an event that said "user changed selection." Then the controls that, say, sent a request to the server for a new set of directions would query the object for the current state. Couple of advantages here. 1. It's UI-agnostic. That is, the other controls on the page don't have to care how it's actually rendered at all. 2. It's encapsulated. There's a single way to get the selected direction type. 3. It's much more test friendly. You've essentially abstracted away the DOM for that control. The hard bit about doing this in JavaScript is it's unenforcable in a team environment. What's stopping the other devs from reaching in to the DOM and querying for the selected button? Hope that helps a bit...

jay_kyburz 14y ago

Heads up cloudability. If front end and UI is important may I suggest a different font for the blog. Really hard to read here on windows.

sktrdie 14y ago
Seems pretty readable to me. Plus, color contrast is more in the area of making things look good, which is not what the UI does.
- FrancescoRizzi 14y ago
  Not to be polemic, but I agree that there's something in the current typographic settings that could be improved. I tried to disable the CSS rule from corporate.css::1 on body for font-family (making the font fallback from 'Myriad pro' to the Helvetica family from foundation.css::75) and I think the result is much more readable - although it still has space for improvement in line-height and contrast). HTH

maytc 14y ago

Ironic but your fonts and javascripts are not loading on my chrome

christianreed 14y ago

I've also had issues getting the Cloudability blog through my feed reader in the past.