AMD and Dojo 1.7 questions - dojo

Simple question.
Does AMD DOJO implementation support these type of declarations?
text!./plain.html
define(["../Widget","text!./plain.html"],
function(Widget,plain){
return new Widget({name:"mainApp",template:plain});
});
Load non-modules, let's say underscore.js
require(['dir/underscore.js'], function(){
_.reduce ...
});

Yes, but the precise syntax is different to that used in the question.
The Dojo Loader (1.7)
Plugins
dojo/text
The plugin for loading character data is dojo/text.
The extension should not be used when loading a JavaScript library and the location of the file is set via either a relative of the dojotoolkit base or a packages location declaration in dojoConfig:
require(['underscore'], function( _ ){
_.reduce ...
});
Configure the namespace in the Dojo configuration to avoid messy import paths - see dojoConfig in the loader documentation.
Also, consider using the dojo/global module and/or defining a Dojo module as a wrapper for Underscore.js:
//_.js
define(['dojo/global', 'underscore'], function(global){
return global._
});
With the above consideration, you must have loaded the actual .js file manually. If in conjunction with the dojo/text plugin, one would create a wrapper which also loads the required JS and evaluates it, following could do the trick.
/var/www/dojo-release-1.7/ext_lib/_.js - this sample file is hierachially placed in a library namespace, alongside dojo, dijit, dojox
define(['dojo/global', 'dojo/text!./Underscore.js'], function(global, scriptContents){
global.eval(scriptContents);
return global._ // '_' is the evaluated reference from window['_']
/**
* Alternatively, wrap even further to maintain a closure scope thus hiding _ from global
* - so adapt global.eval to simply eval
* - remove above return statement
* - return a dojo declared module with a getInstance simple method
*/
function get_ () { return _ };
var __Underscore = declare('ext_lib._', [/*mixins - none*/], {
getInstance: get_
});
// practical 'static' reference too, callable by 'ext_lib.getInstance' without creating a 'new ext_lib._'
__Underscore.getInstance = get_;
return __Underscore;
});
A sample of defining own modules using declare here
Note: this code is untested; feel free to add corrections.

Related

Handlebars with Assemble build returning "not an own property of its parent"

I am experiencing the dreaded not an "own property" of its parent issue when attempting to build my Handlebars project.
I have been down the rabbit hole and seen the many explanations of using #handlebars/allow-prototype-access to allow the issue to be bypassed, however it seems the project does not use a standard implementation of Handlebars...
It seems I am using something called engine-handlebars
Where I would expect to implement that allow-prototype-access change, I see the following:
app.pages('./source/pages/**/*.hbs');
app.engine('hbi', require('engine-handlebars'));
I can't fathom how I am supposed to implement the prototype access with this setup...
It seems, after a bit of trial and error, commenting lines out as I go, that the line app.pages('./source/pages/**/*.hbs'); is actually causing the issue...
When I run the project with this line in, I get the error:
Handlebars: Access has been denied to resolve the property "path" because it is not an "own property" of its parent.
You can add a runtime option to disable the check or this warning:
See https://handlebarsjs.com/api-reference/runtime-options.html#options-to-control-prototype-access for details
[10:54:49] ERROR - undefined: Cannot read property 'substring' of undefined
The plugin #handlebars/allow-prototype-access works by modifying the Handlebars instance.
const _Handlebars = require('handlebars');
const { allowInsecurePrototypeAccess } = require('#handlebars/allow-prototype-access');
const Handlebars = allowInsecurePrototypeAccess(_Handlebars);
Note that allowInsecurePrototypeAccess does not modify the instance in place, but creates an isolated instance via Handlebars.create() so you must use its return value.
In your case, engine-handlebars exposes the Handlebars instance in different ways depending on what version you are using.
Based on your code you provided, my guess is you are using <1.0.0, but I'll provide methods for adjusting this for all its versions.
engine-handlebars#<0.6.0
Unfortunately these versions don't expose Handlebars in any way, so if you are using this version I recommend upgrading engine-handlebars to a later version.
engine-handlebars#>=0.6.0 <1.0.0
Version 0.6.0 exposed Handlebars as a property on the exported engine function. This is then referenced throughout the library via this.Handlebars.
You can then change this before setting the app.engine() and it should work.
const _Handlebars = require('handlebars');
const { allowInsecurePrototypeAccess } = require('#handlebars/allow-prototype-access');
const engine = require('engine-handlebars');
// elsewhere...
// const app = ...
// Do this *before* setting app.engine
const insecureHandlebars = allowInsecurePrototypeAccess(_Handlebars);
engine.Handlebars = insecureHandlebars;
app.engine('hbi', engine);
engine-handlebars#>=1.0.0
For version 1.0.0 and beyond, you must pass the Handlebars instance yourself.
const Handlebars = require('handlebars');
const engine = require('engine-handlebars')(Handlebars);
Thus you don't need to set anything on engine, you just pass in the modified instance when you need it.
const _Handlebars = require('handlebars');
const { allowInsecurePrototypeAccess } = require('#handlebars/allow-prototype-access');
// elsewhere...
// const app = ...
// Do this *before* setting app.engine
const insecureHandlebars = allowInsecurePrototypeAccess(_Handlebars);
const engine = require('engine-handlebars')(insecureHandlebars);
app.engine('hbi', engine);

What globals are available in template expressions?

I'm reading the Vue.js guide, and I've come across the statement.
Template expressions are sandboxed and only have access to a whitelist
of globals such as Math and Date. You should not attempt to access
user defined globals in template expressions.
What are all the globals available in templates?
That is, what is the content of the whitelist, exhaustively?
Vue.js defines the whitelist of globals in the core/instance/proxy.js file:
//...
const allowedGlobals = makeMap(
'Infinity,undefined,NaN,isFinite,isNaN,' +
'parseFloat,parseInt,decodeURI,decodeURIComponent,encodeURI,encodeURIComponent,' +
'Math,Number,Date,Array,Object,Boolean,String,RegExp,Map,Set,JSON,Intl,' +
'require' // for Webpack/Browserify
)
// ...
When Vue compiles the template, the string interpolations are processed, and if you reference a global that is not whitelisted, you will have a warning on Development.
If you are curious about how templates are compiled to render functions, look through the template explorer.
From what I understood from source code globals are declared in a variable and make it available via a proxy between vm instance and template :
const allowedGlobals = makeMap(
'Infinity,undefined,NaN,isFinite,isNaN,' +
'parseFloat,parseInt,decodeURI,decodeURIComponent,encodeURI,encodeURIComponent,' +
'Math,Number,Date,Array,Object,Boolean,String,RegExp,Map,Set,JSON,Intl,' +
'require' // for Webpack/Browserify
)
So gobals available in template are :
Infinity
undefined
NaN
isFinite
isNaN
parseFloat
parseInt
decodeURI
decodeURIComponent
encodeURI
encodeURIComponent
Math
Number
Date
Array
Object
Boolean
String
RegExp
Map
Set
JSON
Intl
require
If you try to put in your template a reference that is not whitelisted or not in your vm instance then you will have this warning :
Property or method "${key}" is not defined on the instance but
referenced during render. Make sure that this property is reactive
either in the data option, or for class-based components, by
initializing the property.

Cant access helper methods inside mongoose schema

My directory looks like bellow
--controllers
-helper.js
--models
-userModel.js
--server.js
My helper module is like
module.exports = {
check: function() {
return 'check';
}
}
I want to access helper module inside userModel.js. So I put like
var helper = require('.././controllers/helper');
Then I do console.log(helper.check()); but it shows error helper.check is not a function Or if I do console.log(helper); only it returns {}. How to access the helper module inside models? Thank you.
Since you said it returns {}, can you please check in your helper module that you have imported userModel.js. Because it forms circular dependencies and sometimes result empty json.

Reference a class' static field of the same internal module but in a different file?

I'm using TypeScript and require.js to resolve dependencies in my files. I'm in a situation where I want to reference a static field of a class in an other file, but in the same internal module (same folder) and I am not able to access it, even if the Visual Studio pre-compiler does not show any error in my code.
I have the following situation :
Game.ts
class Game {
// ...
static width: number = 1920;
// ...
}
export = Game;
Launcher.ts
/// <reference path='lib/require.d.ts'/>
import Game = require("Game");
var width: number = Game.width;
console.log(width); // Hoping to see "1920"
And the TypeScript compiler is ok with all of this. However, I keep getting "undefined" at execution when running the compiled Launcher.ts.
It's the only reference problem I'm having in my project, so I guess the rest is configured correctly.
I hope I provided all necessary information, if you need more, please ask
Any help is appreciated, thanks !
Your code seems sound, so check the following...
You are referencing require.js in a script tag on your page, pointing at Launcher (assuming Launcher.ts is in the root directory - adjust as needed:
<script src="Scripts/require.js" data-main="Launcher"></script>
Remove the reference comment from Launcher.ts:
import Game = require("Game");
var width: number = Game.width;
console.log(width); // Hoping to see "1920"
Check that you are compiling using --module amd to ensure it generates the correct module-loading code (your JavaScript output will look like this...)
define(["require", "exports", "Game"], function (require, exports, Game) {
var width = Game.width;
console.log(width); // Hoping to see "1920"
});
If you are using Visual Studio, you can set this in Project > Properties > TypeScript Build > Module Kind (AMD)
If you are using require.js to load the (external) modules, the Game class must be exported:
export class Game {}
If you import Game in Launcher.ts like
import MyGame = require('Game')
the class can be referenced with MyGame.Game and the static variable with MyGame.Game.width
You should compile the ts files with tsc using option --module amd or the equivalent option in Visual Studio

What is dojo equivalent of $('body')?

The following methods returns object
dojo.body()
but we can not addClass on it (or any other operation) ?
Please see http://dojotoolkit.org/reference-guide/1.9/dojo/query.html for information on using dojo/query especialy with AMD. dojo/query returns NodeList - an array just like $('.someSelector'). Note that to do something like $('body').addClass('class') you'll need to require dojo/NodeList-dom.
So basic example of adding class using dojo/query (and AMD) would be
require(["dojo/query", "dojo/NodeList-dom"], function(query){
query("body").addClass('class');
});
For the full list of NodeList methods see Dojo docs. Methods could be defined in different modules so look for "Defined by dojo/NodeList-dom" below method name.
In the current versions of Dojo (see 1.9), the technology has changed. To access the body, one would now code:
require(["dojo/_base/window"], function(win) {
var myBody = win.body();
});
To add a class, one would code:
require(["dojo/_base/window", "dojo/dom-class", function(win, domClass) {
domClass.add(win.body(), "someClass");
});
See also:
http://dojotoolkit.org/reference-guide/1.9/dojo/_base/window.html#dojo-base-window-body
http://dojotoolkit.org/reference-guide/1.9/dojo/dom-class.html#dojo-dom-class-add