On 5/8/16, 2:36 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>I’m going through Flash code and converting it to FlexJS… > >Is there any reason there’s no flex.utils.TimerEvent for Timer event >constants? If not, I’ll add it… Well, one thing I wanted to do differently in FlexJS vs Flex was have fewer event classes. Each Event subclass takes up download and initialization time. So my plan for FlexJS was to only have "generic" event classes like Event and ValueEvent and ValueChangeEvent and hopefully fewer other subclasses where the number of other payload properties and names of those payload properties would be important, and specify constants in the classes that generate the event. So, in short: no TimerEvent class, but you are correct that we don't have a const to use so we should add a TIMER constant to the Timer class itself (and use it within). More detail: In Flex, there are lots of Event subclasses, with Event constants, and other properties, but often, those properties are not really needed on the event object. Most folks can safely take a CHANGE event and examine the selectedItem in the DataGrid. It wastes cycles to copy the selectedItem into the Event and pass it around if you can just check the event.target.selectedItem. Sure, it isn't a lot of cycles, but it might all add up, especially when events are flying around like crazy at startup. So, in FlexJS, I would like to try not copying properties to the Event object if it is "stable". Now, the oldValue of a ValueChangeEvent is not "stable" because there is no way to examine the event.target to find the oldValue, so yes, you have to at least have an Event subclass that sports an oldValue property, and it makes sense to have the "newValue" in there as well. Bunches of other event classes just have zero or one property. So in FlexJS I added a ValueEvent which has a generic value property typed as Object. Timer maybe should dispatch this Event instead and include the currentTime, since that is also "unstable". By the time your code gets around to examining the time in response to the event, the value may be incorrect. Anyway, I'm not going to be strict about this. The usability of having an Event with a currentTime instead of a generic "value" property may be worth the extra download and startup time. I just wanted to see how the pattern looked and felt to see if we could save a few bytes and cycles here and there. In the regular Flex SDK, it is as big and slow as it is partly because we kept opting to take the minimal size hit until we took the hit so many times it added up to something. I'd like to avoid that in FlexJS if possible, but the APIs also have to be easy to work with. -Alex
