Hi everyone, One more point I would like feedback on is the whole concept that I implemented here.
Basically, I was being forced to push up functionality into common super classes to keep my code DRY, but only a small number of sub- classes used the functionality and I didn't want a bloated/uber/ kitchen-sink super class. With javascript being so flexible at runtime, composing functionality on an as-needed basis seemed like a natural way to go (see the below except from the README for the concrete case with backbone.Views). Is this a good idea or are there some fundamental problems with this approach? (one constraint is that mixins should be done in super classes first before subclasses if they both mixin the same thing so they get mixed-in only once...you'll get an exception otherwise with a clobbering wanring) Kevin ******************** The problem I had was that I was implementing Backbone.Views. Some of them needed scrollable content areas (using iScroll), some of them needed to be dynamically rendered based on Backbone.Models loading and unloading whereas others needed to render collections, some of them needed to have timers to change state after a specific timeout, all of them had custom destroy methods to unbind jQuery events, some views needed to subscribe to state changes on other views, etc. My base view class was becoming a kitchen sink class and I thought, there's got to be a better way! So I started on the path of factoring out each aspect, providing initialize and destroy code for each, and mixing-in functionality on the fly. Now, I have a very simple view base class that only provides the minimal & common view functionality (it actually doesn't even need to be a Backbone.View anymore since all the functionality is now in mixins) and a view hierarchy two deep. Each view is simple to read, light on code, and customized to meet its unique needs. On Oct 10, 8:56 am, kmalakoff <[email protected]> wrote: > Hi everyone, > > In a personal project, I started using Javascript mixins quite heavily > and recently refactored out the code into a > library:https://github.com/kmalakoff/mixin > > I've been using and improving this over the last 3 months and I'm > really excited about sharing it with the JS community, but I'm not > sure what people think especially since playing around with prototypes > can be frowned upon. > > The only feedback I have received so far is that is might be hard to > debug and seemed a bit complex. For debugging, I implemented a > statistics module to be able to look at memory usage and would argue > that the complexity matches the problem, but I'd like to get some more > feedback! (thank you Angus for suggesting jsmentors) > > Here are three blog posts with examples so you know what I'm trying to > achieve: > > 1)http://braincode.tumblr.com/post/11026285083/mixin-js-the-javascript-... > 2)http://braincode.tumblr.com/post/11100271168/mixin-js-view-with-model... > 3)http://braincode.tumblr.com/post/11265571365/mixin-js-subscriptions-e... > > The above GitHub repository has tests both for the library and for the > initial 7 mixins I released (RefCount, Flags, AutoMemory, > Subscriptions, Timeouts and 2 or Backbone.js) and the working examples > from the blog posts can be found > here:https://github.com/kmalakoff/examples-kmalakoff > > Any feedback would be much appreciated. > > Cheers, > > Kevin -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
