Hi there,
Actually, there is one thing I’ve thought about quite a bit that’s been, well, not impossible to work with, but something I thought could be done better; events.
There’s a few events here and there in the system, in different objects, and so on, however they’re not always consistently named or placed in context (ie. ready vs. onReady), sometimes they’re named with or without their source (ie. loaded vs. tileLoaded), sometimes plain events, sometimes Promises, sometimes callbacks, and so on. Sometimes an event returns a known error class instance, other times “some data” you have to figure out, and so on. Sometimes you get an Event error, and a Promise ready (that sometimes is called readyPromise, other times just ready). You have the same system across all the various collections, so instead of Collection.added/removed/changed, we get named events like Collection.dataSourceAdded/dataSourceMoved/dataSourceRemoved when we already know it’s a Collection for DataSources. Would be nice to have a simpler model that’s consistent across it all (if just for using proxy functions) with just Collection.added/removed/changed, etc. think like a Collection interface.
Then there’s all these things I wish there were events for, for example with EntityCollections instead of three different events, we get this compound; CollectionChangedEventCallback(collection, added, removed, changed), but I would love that split into individual events. And … what does ‘changed’ mean? There’s no info on what has changed, so I have to invent some kind of change detection to figure it out, even though I suspect you already have one hidden in there somewhere … (never mind that it’s a Collection with a CollectionChanged name…)
Which leads me to the lifecycle thing; an event triggers because something happened, however for the most part we get no events for things that are about to happen. For example, I might get a CollectionChangedEventCallback(collection, added, removed, changed) where I find some entity removed, however by that time it’s often too late, for example I had some callback function in the render cycle attached to it, and now I get a crash unless I do checks like against this, which feels counter-intuitive. It would be great to have a before and after event, like EntityRemovedBefore(entity) (and if you want to be fancy, timed ones to allow for reactions to events, as in “about to be removed in 5 ms”), or go the full hog with a lifecycle event structure (as in, all events gets init,begin,during,end events).
Some collections don’t even have events, like PointPrimitiveCollection (or any primitive collection) or PolylineCollection. And some places there’s callbacks instead of events, like PropertyBag can be instantiated with a createPropertyCallback (which has the description “A function that will be called when the value of any of the properties in value are not a Property” which, uh, I’m having a hard time understanding 
). There are other places that uses callbacks where events make sense, and probably vice-versa.
All in all, and just off the top of my head (I didn’t do extensive research into this, it’s just from memory working with the API over the years), it would be great to maybe tidy up some of these things. More and more applications are becoming event-driven (I do a lot of RxJS event driven stuff, and I often have to proxy and hack around the API to make it work).
Having basic event listeners is fine and all, but there are also lots of things we could do to make things more consistent, more efficient, leaner, and by extension, easier to understand through simpler, more consistent and more plentiful events.
Anyway, just my little input there.
Cheers,
Alex
