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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>
>
