Is there a proper way to include environment variables in a .ts file? They are declared in wrangler.toml or through the CLI, but Typescript won't know they are there.
Currently I either use a .js file to declare these vars and then import into a .ts
//env.js
const SOMEVAR = SOMEVAR
Or I will need to use a #ts-ignore comment.
I've tried process.env but as expected this fails as the script isn't run in Node.
You can inform TypeScript of your global variables by using the declare global { ... } syntax in your script:
declare global {
const SOMEVAR: string
const ANOTHERVAR: string
}
// now you can use SOMEVAR and ANOTHERVAR as global vars
Related
test2.xqy:
import module namespace myNS = "http://test.org/module1" at "./namespace.xqy";
element test
{
}
namespace.xqy:
module namespace myNS = "http://test.org/module1";
declare variable $myNS:srcDoc:="test2.xml";
declare variable $myNS:defaultXMLNS:="http://www.test.com#";
declare variable $myNS:defaultXMLBase:=$defaultXMLNS;
Command line:
$ basex test2.xqy
Stopped at /Users/jack/Documents/xqy/namespace.xqy, 5/53:
[XPST0008] Undefined variable $defaultXMLNS.
I didn't find doc about how to import vars and functions from external modules. So I try it in a intuitive way. The error says there is no definition for $defaultXMLNS. I did define it, but with a namespace prefix.
You forgot to define the namespace on the right-hand side of the assignment:
declare variable $myNS:defaultXMLBase:=$defaultXMLNS;
(: ^ no namespace defined :)
Thus, $defaultXMLNS is searched in the default namespace, where it is not registered. Apply the namespace instead:
declare variable $myNS:defaultXMLBase:=$myNS:defaultXMLNS;
If you do so, you can later access the value like this:
import module namespace myNS = "http://test.org/module1" at "./namespace.xqy";
element test
{
$myNS:srcDoc
}
here is the code of an alloy controller written in two different ways. Although the both work the same, Which one might be best practice?
example 1 of controller.js:
var currentState = true;
$.getState = function(){
return currentState;
}
example 2 of controller.js:
var currentState = true;
exports.getState = function(){
return currentState;
}
Titanium is based on the CommonJS framework. The exports variable is a special variable used typically to expose a public API in a class object. So when you want to expose a method of doSomething() on the MyModule.js class you would use the exports variable like this:
exports.doSomething() = function(args) {
//Some really cool method here
};
Then reference that class using
var myModule = require('MyModule');
myModule.doSomething();
However when referencing a view object the typical way to reference the is using the $. shortcut. You can see they prefer that method in the official documentation.
http://docs.appcelerator.com/platform/latest/#!/guide/Alloy_XML_Markup
The $ variable holds a reference to your controller instance. It also contains some references to all indexed views (understand, views for which you supplied an index in you xml markup).
Both ways are strictly equivalent as, during the compilation, Alloy will merge the content of the exports with your controller referenced in $. Adding them directly to the instance won't change a thing.
Neverthless, developers are used to see the public API as the set of functions exported via the special variable exports; Thus, I will recommend to keep using it in a clean and clear way (for instance, defining your functions in your module scope, and only expose them at the end or beginning of your controller).
function myFunction1 () { }
function myFunction2 () { }
function myFunction3 () { }
exports.myFunction1 = myFunction1;
exports.myFunction3 = myFunction3;
Thereby, your API is quite clear for people diving into your source code. (A readMe file is also highly recommended :) ).
Where do I define the functions that I want to use across the client code? Is it fine to define it with Template.registerHelper() although it is not necessarily intended to use inside templates? I want to be able to do something like util.calculateDistance(a,b) in any client code base.
You can define the method globally or on a global object (don't use the var keyword to make it global):
util = {} //instead of var util = {}
util.calculateDistance = function(a,b) {....}
I want to write some helper functions that I can use in my other JavaScript files.
It says here:
Some JavaScript libraries only work when placed in the client/compatibility subdirectory. Files in this directory are executed without being wrapped in a new variable scope.
It seems a bit bizarre to me that I should have to throw all my libraries in a folder called compatibility. Generally "compatible" stuff is for legacy code that hasn't been upgraded to the new style. Is there no way to export modules so that I can access them in my other files?
Using this pattern now:
Util = (function(exports) {
exports.getFileExtension = function(filename) {
var i = filename.lastIndexOf('.');
return (i < 0) ? '' : filename.substr(i);
};
// more functions
return exports;
})(typeof Util !== 'undefined' ? Util : {});
Not sure if that's the best or not...but it appears to work.
It would be bizarre, you are right. Write your own code, just put it somewhere and it works. This refers to complicated frameworks that make a lot of functions all over the place, where no one has 'tamed' them to only expose a root object that all its powers spring from.
Please read "Namespacing and Modules" at
http://www.meteor.com/blog/2013/08/14/meteor-065-namespacing-modularity-new-build-system-source-maps
It's helping you with built in maintainability for avoiding collisions with other things you write, which is largely what namespaces is for.
A good practice is to have your own helper object, named helper or util, where you put grouped things:
utils = {
distance_between: function(lat1,lng1,lat2,lng2) {
var radiusEarth = 3963.1676; // miles radius earth
var dLat = deg2rad(lat2-lat1); // deg2rad below
...
displayHumanReadableTime: function(timestamp){
var a = new Date(timestamp);
If the intention is to write Utility method then it can be written using the ECMA6 Script standard.
Write your method by exporting once in method.js and use it by importing in the desired file(s)
Ex:
export const MyUtilityMethod = function (){...} in /method.js
import {MyUtilityMethod} from './method.js'
Hope this helps.
Despite if it is good practice or not, I read here that you can have package variables (or constants), so I tried this:
// globals.as
package global
{
public const someConst:String = 'theValueOfTheConst';
public var someVar:String = 'theValueOfTheVar';
}
// SomeClass.as
package pack.to.the.class
{
// ...
import global.*;
// ...
// ...
public function aFunction():void
{
trace(someConst);
trace(someVar);
}
// ...
}
And all I have is an Compile-time Error that says "Definition of global:someConst has not been found" (the same for someVar)
I'm using Flex and I see this in Problems. So, is this possible? Can I have package variables (or constants) without using a Class?
Thanks!
PS: The package names, the variables names and function names are all an example, I use other names when I tested.
The answer is quite simple. You may just have one definition in your file. Split them into two files and it works.
And your file has to be named exactly like the variable. So in your example, this would work:
//someConst.as
package global
{
public const someConst:String = 'theValueOfTheConst';
}
//someVar.as
package global
{
public var someVar:String = 'theValueOfTheVar';
}
Each "compilation unit" (fancy term for *.as file) may have only one visible definition. You can also not put two classes into the same file. However you may have as many anonymous definitions as you want.
if you change
public const someConst:String = 'theValueOfTheConst';
to
public static const someConst:String = 'theValueOfTheConst';
then it works for me. YMMV.
I severely doubt it... and if you could I will suspect it's more effort than simply making a global class.
For what it's worth, I tried testing it out myself and couldn't get it to work either, even when the variables and the references to them were in the same package.
Certainly possible, but discouraged. In your source/root (main source folder in the compiler settings) put your global class:
package
{
public const someConst:String = 'theValueOfTheConst';
}
(oh... and I'm using flex to test, but she worked -- no need to import to get someConst in a different package locale)