Some thoughts on extensibility

I've noticed what may or may not be a trend in the newer versions of enyo. It seems the new parts of the framework are beginning to contain more private components. I have run into a few cases where I think this is unnecessarily inhibiting.

I understand sometimes it feels nice to 'protect' the more delicate parts of the framework to keep the fundamentals in working order, but it can also be quite limiting. Traditionally one of the great things about enyo for me was that anything and everything (apart from some parts of the routing implementation) was completely extensible.

I have already had to create my own clone of enyo.Router because I wanted to make a few tiny adjustments that weren't possible by extending the default router, but now with version 2.5 the Store, Relation and RelationalCollection have gone fully private (and that's just the ones I ran into, I don't know if there are more).

If there isn't any particular reason why extending these components would make the entire framework burst into flames, I would kindly request they are exposed again. Now that they're private I might have to simply copy-paste their code into a few new custom kinds, but it'd be nicer if the originals could be extended.


  • Thanks! I'm looking forward to having enyo's internals opened up again if the powers that be will allow it :smiley:
  • Another note on keeping things extensible: The enyo.Model does all of it's setup in the constructor, which is also very limiting.

    The traditional enyo style was one where the constructor and create functions have two distinct roles:
    - The constructor sets up any options, properties, bindings, events, handlers, observers etc. that will be used by the kind instance.
    - The create method executes any actions that need to happen immediately when the kind is instantiated.

    The new Data layer ignores this as well. Currently, if I want to add things to the instance at construction time before my new instance optionally commits or fetches data, I have to re-implement the entire constructor. It would be much easier if there was a 'create' method for all that fetching and committing.
  • At this point I don't think it's limited to just the power user anymore. When it comes to the data layer it's more like a sudden shift from "have it your way" to "our way or the highway", which is disappointing to be honest.
Sign In or Register to comment.