JS Object lifecycle suggest practices

Often we will end up have a lots of zombie object/event do nothing when writing interactive app. It just show a simple example and suggestion on programming practices to avoid it.

Transcript

1. Js Object LifeCycle When you write interactive app Rick Mak, June 2012 Tuesday, 19 June, 12
2. Brief Layering of FileSq Scroll Layer Document Rect Layer (Display of all comments) Annotate Layer Ruler Layer Link-up Layer Tuesday, 19 June, 12
3. Everyone do this in office, not just one. What’s wrong? Tuesday, 19 June, 12
4. It is fine for 80% of sites Browser will just start a new js environment on page navigate zombie object is not noticeable You browser will is fine with ~10,000 zombie events/objects. Tuesday, 19 June, 12
5. General Problem Difficult to read The API tell nothing about the logic, initialize do everything from render, binding to sync The Code is not symmetric It just don’t detach things it create Tuesday, 19 June, 12
6. Problem in FileSq FileSq have only hundreds of elements, but introduces 20k+ event binding. The Document View Flash, as everything just create/destroy and rebind(without unbind) for ease of programmer Tuesday, 19 June, 12
7. T rap of jQuery/backbone How many time you just call jQuery.bind(on), but not unbind(off) The handy events/el/model construction. Make developer don’t aware of the model become zombie even you called View.remove() Tuesday, 19 June, 12
8. Simple practice Count your bind/unbind in a class Make the things symmetric, i.e. if there is delegate, there should be undelegate. bindAdd<=>unbindAdd, initialize<=>destory Tuesday, 19 June, 12
9. On DOM event One object bind to one DOM element Use delegate whenevner possible, and undelegate. When you have to bind a event to a child, you need to unbind. Tuesday, 19 June, 12
10. On JS autonomy You create, you destroy You bind, you unbind I should only talk with JS Object API outside my assigned DOM. I should expose Public method if other need to modify my DOM. Tuesday, 19 June, 12