In my experience, doing anything halfway serious always requires some overrides that include existing code. And even interceptor and sequence don't always allow you to avoid copying some existing code into your function (depends on where you have to inject your new logic). Speaking for myself, it would be impossible for me to ship my calendar components without some overrides that must, by nature, include some Sencha code. YMMV.
Originally Posted by firstname.lastname@example.org
Sencha - Ext JS Dev Team
It's curious; I am newcomer to JS scene and this is exactly what got me off guard at first, the encouraged way of copying/pasting large amounts of existing code in order to override it. I still can't understand it though, what is the reason behind monolithic design? Maybe I'm missing something.
Anyway, I think I have found a way to deal with it, of sorts: when I encounter a large method I need to override, I create a buffer class first, refactor that method and split it up into well-defined parts and then extend that buffer class. Sure it adds overhead on maintaining the buffer class but it's largely alleviated with revision control tools, and it keeps my code clean of any Sencha code. In the end it means easier maintenance for me, without actually adding any significant overhead; and if I don't release that code to the public it means no licensing issues whatsoever. Nice and neat.