What do we currently do with window?
global in Node is the same as window in the browser. All global variables are
attached to the global object.
global[“foo”] could compile to global[“foo”], global.foo, or just plain foo,
and it all means the same thing.
> On Jul 13, 2017, at 2:14 AM, Alex Harui <aha...@adobe.com.INVALID> wrote:
>
> What AS do you want to write and what JS do you want as output?
>
> -Alex
>
> On 7/9/17, 12:53 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>
>> Checking for window will work for Node, but it will not work for Electron.
>>
>> I tried adding global to Falcon, but I was obviously going about it
>> wrong, because what I tried did not work.
>>
>> This is not really high priority for me right now, so I’m moving on to
>> something else…
>>
>>> On Jul 6, 2017, at 3:05 AM, Alex Harui <aha...@adobe.com.INVALID> wrote:
>>>
>>> I've noticed lots of advice on the internet to use feature detection
>>> instead of browser/runtime detection. Did you rule out doing that?
>>> Browsers may implement new features over time.
>>>
>>> But otherwise, I see some clever tests that check for "window" and a few
>>> other things.
>>>
>>> HTH,
>>> -Alex
>>>
>>> On 7/5/17, 1:54 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>>>
>>>> No. I was trying to use process to check whether it’s running in a Node
>>>> runtime (such as Node or Electron). window does not have process.
>>>>
>>>> I’m trying to add a class that lets the client know what environment
>>>> it’s
>>>> running in.
>>>>
>>>> Adding global sounds like a good idea. Between window and global, I
>>>> think
>>>> that would offer a solution everywhere.
>>>>
>>>>> On Jul 5, 2017, at 7:48 PM, Alex Harui <aha...@adobe.com.INVALID>
>>>>> wrote:
>>>>>
>>>>> Sure, I know it wouldn't work at runtime, but it sounded like Harbs
>>>>> couldn't even get the compiler to accept window["process"] which it
>>>>> should.
>>>>>
>>>>> So, it should be ok to write:
>>>>>
>>>>> if(typeof window !== "undefined")
>>>>> {
>>>>> theProcess = window["process"];
>>>>> }
>>>>> else
>>>>>
>>>>> theProcess = global.process
>>>>>
>>>>> But is there really a process property in the browser?
>>>>>
>>>>> We could create or own single variable if we want. How often do
>>>>> libraries
>>>>> need stuff in window/global? Classes that need it should be able to
>>>>> use
>>>>> inject_html and run some JS that maps window to global or the other
>>>>> way
>>>>> around.
>>>>>
>>>>> HTH,
>>>>> -Alex
>>>>>
>>>>> On 7/5/17, 6:43 AM, "Josh Tynjala" <joshtynj...@gmail.com> wrote:
>>>>>
>>>>>> Node.js doesn't have a window variable, so window["process"] won't
>>>>>> work.
>>>>>> They have a global variable instead.
>>>>>>
>>>>>> I remember reading that there is a proposal for ECMAScript to
>>>>>> standardize
>>>>>> a
>>>>>> single variable that refers to window in the browser and global in
>>>>>> Node.js,
>>>>>> but that doesn't exist yet.
>>>>>>
>>>>>> - Josh
>>>>>>
>>>>>> On Tue, Jul 4, 2017 at 11:35 PM, Alex Harui
>>>>>> <aha...@adobe.com.invalid>
>>>>>> wrote:
>>>>>>
>>>>>>> What class in Core needs this dependency? I think one drawback is
>>>>>>> that
>>>>>>> users of that class will need to add node.swc to their project
>>>>>>> dependencies. But I don't think every consumer of Core will need
>>>>>>> node.swc.
>>>>>>>
>>>>>>> But first, why didn't window["process"] work? In theory Falcon will
>>>>>>> let
>>>>>>> you access anything off of window. We could also add global if we
>>>>>>> want.
>>>>>>> Or maybe we should only allow global and have some bootstrap code
>>>>>>> that
>>>>>>> maps global to window?
>>>>>>>
>>>>>>> -Alex
>>>>>>>
>>>>>>> On 7/4/17, 2:09 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Actually, I see that the Node typedefs has all the process
>>>>>>>> declarations
>>>>>>>> in global.js.
>>>>>>>>
>>>>>>>> Is there an issue with adding a dependency in CoreJS to node.swc?
>>>>>>>>
>>>>>>>> Should a class that has this dependency go somewhere else? (I don’t
>>>>>>>> really see an issue with adding the dependency, but I’m throwing
>>>>>>>> this
>>>>>>> out
>>>>>>>> in case I’m missing something.)
>>>>>>>>
>>>>>>>> Harbs
>>>>>>>>
>>>>>>>>> On Jul 5, 2017, at 12:00 AM, Harbs <harbs.li...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> Looks like it.
>>>>>>>>>
>>>>>>>>> I see this in missing.js:
>>>>>>>>>
>>>>>>>>> /**
>>>>>>>>> * @export
>>>>>>>>> * This gets mapped to org.apache.flex.utils.Language.trace() by
>>>>>>>>> the
>>>>>>>>> compiler
>>>>>>>>> * @param {...} rest
>>>>>>>>> */
>>>>>>>>> function trace(rest) {}
>>>>>>>>>
>>>>>>>>> /**
>>>>>>>>> * @type {!Console}
>>>>>>>>> * @const
>>>>>>>>> */
>>>>>>>>> var console;
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I guess I can add another one like so:
>>>>>>>>>
>>>>>>>>> /**
>>>>>>>>> * @type {!Process}
>>>>>>>>> * @const
>>>>>>>>> */
>>>>>>>>> var process;
>>>>>>>>>
>>>>>>>>> However, it seems like a drag to have to add a typedef every time
>>>>>>>>> a
>>>>>>>>> developer needs to check for the existence of a global that we did
>>>>>>>>> not
>>>>>>>>> think of.
>>>>>>>>>
>>>>>>>>>> On Jul 4, 2017, at 9:13 PM, Harbs <harbs.li...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Thanks. Here’s what I see:
>>>>>>>>>>
>>>>>>>>>> if(typeof window !== "undefined")
>>>>>>>>>> {
>>>>>>>>>> theConsole = window.console;
>>>>>>>>>> }
>>>>>>>>>> else if(typeof console !== "undefined")
>>>>>>>>>> {
>>>>>>>>>> theConsole = console;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> Did you define console in a typedef maybe?
>>>>>>>>>>
>>>>>>>>>> I’m thinking that Falcon should really allow undefined variables
>>>>>>> when
>>>>>>>>>> used with “typeof”.
>>>>>>>>>>
>>>>>>>>>> Truth be told, I really need to do something like one of these:
>>>>>>>>>> if(typeof (process) != 'undefined' && {}.toString.call(process)
>>>>>>>>>> ==
>>>>>>>>>> '[object process]’)
>>>>>>>>>> or:
>>>>>>>>>> if(typeof process != 'undefined' && process &&
>>>>>>>>>> process.constructor.name == "process”)
>>>>>>>>>>
>>>>>>>>>> Of course every reference to process causes a compiler error. I
>>>>>>> wonder
>>>>>>>>>> if there’s some way to tell the compiler to accept it without
>>>>>>>>>> complaining…
>>>>>>>>>>
>>>>>>>>>>> On Jul 4, 2017, at 8:54 PM, Josh Tynjala <joshtynj...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I don't remember exactly what I did, but in order to get trace()
>>>>>>>>>>> working in
>>>>>>>>>>> Node.js, I had to figure out how to find the console object on
>>>>>>> window
>>>>>>>>>>> versus global. I feel like I remember using typeof, but maybe it
>>>>>>> was
>>>>>>>>>>> something else. Take a look at the implementation of
>>>>>>> Language.trace()
>>>>>>>>>>> to
>>>>>>>>>>> see what I did.
>>>>>>>>>>>
>>>>>>>>>>> - Josh
>>>>>>>>>>>
>>>>>>>>>>> On Jul 4, 2017 5:26 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I’m trying to figure out how to solve this dilemma:
>>>>>>>>>>>>
>>>>>>>>>>>> Browsers attach global variables to window.
>>>>>>>>>>>>
>>>>>>>>>>>> Node.js attaches globals to global.
>>>>>>>>>>>>
>>>>>>>>>>>> I’m trying to check for the existence of a global called
>>>>>>>>>>>> process.
>>>>>>> In
>>>>>>>>>>>> JS,
>>>>>>>>>>>> you’d generally do that by checking typeof process ==
>>>>>>>>>>>> ‘undefined’.
>>>>>>>>>>>> Falcon
>>>>>>>>>>>> does not allow you to do that and complains that process is an
>>>>>>>>>>>> undefined
>>>>>>>>>>>> property. In the browser you can use window[“process”] ==
>>>>>>> undefined
>>>>>>>>>>>> and in
>>>>>>>>>>>> node you can (theoretically) use global[“process”] ==
>>>>>>>>>>>> undefined.
>>>>>>>>>>>> I
>>>>>>>>>>>> can’t
>>>>>>>>>>>> think of a generic way to do this though.
>>>>>>>>>>>>
>>>>>>>>>>>> Thoughts?
>>>>>>>>>>>> Harbs
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>
