You may find that defining constants on the class that uses them doesn't scale well, especially with UI components. That's something I found in Feathers.
If you or someone else creates a subclass, what to do with any constants on the base class? Should they get duplicated in the subclass? Or will users be forced to look up the class hierarchy to figure out where to find a constant? Both approaches have downsides. In Feathers, I ended up duplicating the constants because I saw people getting confused about where to find them. Then, I found myself occasionally forgetting to duplicate some constants when I created subclasses, and things just became messy and potentially even more confusing. That wasn't for event constants in Feathers, though. It was for other types of constants that the components used. However, I think this advice still applies. In Starling, the main Event class works similarly to what you describe. It has a data property that can be used to pass pretty much anything with the event. In Feathers, I ended up creating a FeathersEventType class that defined common event constants so that I could dispatch starling.events.Event instances. This proved to be a nice approach. I could see something like a FlexEventType class for constants, or more specific names for different categories of event constants. - Josh On Sun, May 8, 2016 at 10:36 PM, Alex Harui <aha...@adobe.com> wrote: > > > 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 > > >
