Actually, FalconJX probably doesn’t know that the FlexJS widgets are using
goog.events. So, like you said, folks should be writing against the event
model in any JS framework they are using.
I guess this thread encompasses both what the compiler’s dependencies on
goog is as well as the framework we are writing. If we’re going to use
some of goog in the framework, should we use it elsewhere?
I just remembered another peeve I have about goog.require: it doesn’t
allow circular dependencies, so we end up spending time determining the
dependency order and then rewriting the JS files before sending them to
GCC. Maybe RequireJS or AMD are more forgiving. The folks on GCC are
basically disallowing:
Class ParentNode
{
var childNode:ChildNode
}
Class ChildNode
{
Var parentNode:ParentNode;
}
Instead, to avoid rewriting files, they insist you code by using
interfaces. Sure, that makes sense academically, but why should you
always have to do that.
-Alex
On 5/28/15, 1:06 PM, "Josh Tynjala" <joshtynj...@gmail.com> wrote:
>I'm not sure that it makes sense to include an EventDispatcher with the
>vanilla transpiler. So many JS libraries have their own implementations of
>events. I wonder if developers would be expecting one to be included, or
>if
>they'd prefer pull in an existing library.
>
>- Josh
>
>On Thu, May 28, 2015 at 11:14 AM, Alex Harui <aha...@adobe.com> wrote:
>
>>
>>
>> On 5/28/15, 10:43 AM, "Josh Tynjala" <joshtynj...@gmail.com> wrote:
>>
>> >ES5 is my preference too. I think ES6 would be interesting because the
>> >code
>> >would look a bit closer to AS3, but with the polyfills and the
>> >implementations in browsers being pretty new still, I'm wary of
>>adopting
>> >it
>> >at this point in time.
>>
>> OK, so I think that means that we use some other thing instead of
>> goog.inherit.
>>
>> Do we also want to trade in goog.require/provide for RequireJS, AMD, or
>> something else?
>>
>> What should we do about dispatching events on non-DOM objects? We have
>> that in AS and I think folks will want that in JS. Early on, I had a
>> simple implementation of EventDispatcher for non-DOM objects. We could
>>go
>> back to that, but then that’s just another chunk of code that needs to
>>be
>> debugged. Events for non-DOM objects is pretty simple because it
>>doesn’t
>> have to worry about bubbling.
>>
>> Erik points out that the Closure JSDoc annotations help the minifier. I
>> think the output of FalconJX can still generate the Closure JSDoc, or is
>> there some other minifier that we want to use that uses different
>> annotations?
>>
>> So, in the net, we are only swapping out goog.inherit for now? I think
>> that’s ok with me.
>>
>> -Alex
>>
>>
