I'm using EAK and a canary build of Ember - this was the same with beta & canaray builds from emberjs.com as well as alexpenner's build at http://ember.alexspeller.com/ember-latest.js
So Ember should of course be managed by bower. I am trying to use the 'query-params' feature in EAK, and per the ember guide (http://emberjs.com/guides/routing/query-params/) placed the line
Ember.FEATURES["query-params"] = true;
directly before the App.create line in app.js
Inside the relevant route,
renderTemplate: function( controller, context, queryParams ) {
console.log(queryParams);
}
Would always log undefined, until I added the above features line to the actual Ember source (in the vendor folder :/ ). For instance, right after the features hash is defined in ember.js, adding Ember.feature["query-params"] = true and refreshing would yield the proper params object in the console.
This indicates to me that the feature is working properly in all respects (i.e. the object is being accessed correctly in the app), but I would like to be able to enable the flag in a reasonable place such as app.js
Any idea why it would not work to enable the flag above the app.create line? Is there a different way to approach this in EAK?
You should try putting your environment variables in config/environment.js.
I believe that is the EAK approach.
Related
I'm trying to load multiple modules on the fly via chokidar (watchdog) using Meteor 1.6 beta, however after doing extensive research on the matter I just can't seem to get it to work.
From what I gather require by design will not take in anything other than static strings, i.e.
require("test/string/here")
Since if I try:
var path = "test/string/here"
require(path)
I just get Error: Cannot find module, even though the strings are identical.
Now the thing is I'm uncertain how to go on about this, am I really forced to either use import or static strings when using meteor or is there some workaround this?
watchdog(cmddir, (dir) => {
match = "." + regex_cmd.exec(dir);
match = dir;
loader.emit("loadcommand", match)
});
loader.on('loadcommand', (file) => {
require(file);
});
There is something intrinsically weird in what you describe.
chokidar is used to watch actual files and folders.
But Meteor compiles and bundles your code, resulting in an app folder after build that is totally different from your project structure.
Although Meteor now supports dynamic imports, the mechanism is internal to Meteor and does not rely on your actual project files, but on Meteor built ones.
If you want to dynamically require files like in Node, including with dynamically generated module path, you should avoid import and require statements, which are automatically replaced by Meteor built-in import mechanism. Instead you would have to make up your own loading function, taking care of the fact that your app built folder is different from your project folder.
That may work for example if your server is watching files and/or folders in a static location, different from where your app will be running.
In the end, I feel this is a sort of XY problem: you have not described your objective in the first place, and the above issue is trying to solve a weird solution that does not seem to fit how Meteor works, hence which may not be the most appropriate solution for your implicit objective.
#Sashko does a great job of explaining Meteor's dynamic imports here. There are also docs
A dynamic import is a function that returns a promise instead of just importing statically at build time. Example:
import('./component').then((MyComponent) => {
render(MyComponent);
});
The promise runs once the module has been loaded. If you try to load the module repeatedly then it only gets loaded once and is immediately available on subsequent requests.
afaict you can use a variable for the string to import.
I just started using Ember for a real application, and already got myself into a bit of a bind.
I set up my environment.js file with the following:
modulePrefix: 'appname',
podModulePrefix: 'appname/pods'
However, this did not work and Ember CLI continues to generate files in the old/normal structure. I unfortunately did not even notice until I had a decent amount of work done... cause I was excited just to have an Ember app going! ;)
So the question I have is two-fold:
Why is podModulePrefix not working? I've read up on it, and it seems like it should be fine. I'm probably missing the point on why it's not working.
How can I migrate my existing file structure into the pod structure? Is it just manually doing so, or is there a tool out there that helps with things?
Thanks for any help!
I am going to answer
1- you should just stop Ember and start again and your code should be
podModulePrefix: 'app/pod', //just an example
then start creating a test component like
ember g component test-com --pod
the result would be this
installing component
create app/pod/components/test-com/component.js
create app/pod/components/test-com/template.hbs
installing component-test
create tests/integration/pod/components/test-com/component-test.js
2- no way, you must just simply create and copy and paste your code.
If you would like to use the pods structure as the default for your project, you can set usePods in your .ember-cli config file to true (setting was previously named usePodsByDefault). To generate or destroy a blueprint in the classic type structure while usePods is true, use the --classic flag.
With the usePods set to true.
// .ember-cli
{
"usePods": true
}
I am utterly confused as how to insert individual foundation javascript. it always seem to break my code. for example I need to use the dropdown menu js. in the documentation it state
Initializing
The file foundation.dropdownMenu.js must be included in your JavaScript to use this plugin,
along with foundation.core.js.
This plugin also requires these utility libraries:
foundation.util.keyboard.js
foundation.util.box.js
foundation.util.nest.js
this seem simple enough so I did the following in this order
bower_components/foundation-sites/js/foundation.core.js //check
bower_components/foundation-sites/js/foundation.util.mediaQuery.js
bower_components/foundation-sites/js/foundation.util.timerAndImageLoader.js
bower_components/foundation-sites/js/foundation.util.keyboard.js //check
bower_components/foundation-sites/js/foundation.util.box.js //check
bower_components/foundation-sites/js/foundation.util.nest.js //check
bower_components/foundation-sites/js/foundation.dropdown.js
bower_components/foundation-sites/js/foundation.dropdownMenu.js //check
bower_components/foundation-sites/js/foundation.equalizer.js
I follow what logical for me core 1st than util than plugin
yet it told me foundation.util.nest.js:6 Uncaught SyntaxError: Unexpected token =
if I put all foundation.min.js file the error go away, so I know it must be a dependency is missing or the order is not correct
is there any resource out there that is clear on the dependency of foundation js? instead everytime I have to trail and error it.
I'm having the same issue on my end. I am using Foundation as a GIT subtree in my project and actually have used this on a site I made just last week.
It seems that the problem is a newer version of function parameter declarations. In the code I had working, v6.1.2, the code in foundation.util.nest.js is:
Foundation.Nest = {
Feather: function(menu, type){
menu.attr('role', 'menubar');
type = type || 'zf';
versus the code in the newest version 6.2.0 which is:
const Nest = {
Feather(menu, type = 'zf') {
menu.attr('role', 'menubar');
It's that default/fallback declaration of "type" that seems to ruin everything. I look forward to a fix myself.
According to this link, my current version of Chrome (48) doesn't yet support default function parameters.
As of Foundation v6.2.0 the JavaScript codebase has been updated to ES6.
https://github.com/zurb/foundation-sites/releases
You'll need to add Babel to your build process to compile the ES6 code.
They have supplied a tutorial for this here:
https://github.com/zurb/foundation-sites/wiki/Upgrading-to-Foundation-6.2
Hope this helps.
How can the JavaScript part of a Cordova based application check if a certain plugin is available in the native part?
I tried to use cordova.require( 'cordova/plugin_list' ).metadata but it returns a list of the JavaScripts that have been loaded via cordova_plugins.js. Doing something like if ( typeof( window.plugins.MyPlugin ) != 'undefined' ) doesn't help either - while the JavaScript part of my plugin is loaded, the native part might not be available.
What I basically need is a way to react to these errors (copied from an iOS project)
ERROR: Plugin 'MyPlugin' not found, or is not a CDVPlugin. Check your plugin mapping in config.xml.
-[CDVCommandQueue executePending] [Line 158] FAILED pluginJSON = [
"MyPlugin1093761140",
"MyPlugin",
"someAction",
[]
]
that ocurr when I try to do
cordova.exec( successFn, errorFn, 'MyPlugin', 'someAction', [{}] );
and MyPlugin is not included in the native project.
You could make a plugin which retrieves the list of available plugins. Specifically, you could read the names of classes within the various <feature> tags in the config.xml which is packed within your project. On Android this can be found in the xml folder in the res folder where other resources are. Not sure about where it is on iOS at the moment.
Alternately, you could detect the error within the errorFnthat you had in your example, since it'll be a string that says "Class not found".
Either method is asynchronous however, so it won't be as nice as just checking globals.
As I'm trying to compile my project with breeze and requirejs for production, I'm running into multiple issues. Unrolling this, I tried starting fresh with the Knockout RequireJS example.
After I installed MVS2013Pro I was able to run the project, but not without issues:
window.breeze is defined so it has been leaked to global scope (this
should not happen with RequireJS)
Hitting F5 Refresh will crash with
Uncaught Error: Can't find breeze and/or Q (breeze savequeuing)
Uncaught TypeError: undefined is not a function (breeze dataservice)
With these errors I'm not even trying to establish my grunt requirejs (r optimizer) task. As these are the root of my problems.
Note: I'm not searching for a knockout solution, my stack actually is: MongoDataService+Breeze+SaveQueueing+RequireJS+AngularJS+Socket.IO+Cordova
window.breeze
You're right that breeze sneaks back into the browser way down at the bottom of breeze.debug.js:
if (global.window) {
global.window.breeze = breeze;
}
We don't know why we put that in the code base. No one remembers. Coming at the end as it does, it clearly isn't needed by Breeze itself.
I commented it out in preliminary testing and that seems to do the trick. The window.breeze becomes undefined in the Todo-KO-Require sample; it remains defined (properly) in samples that do not use require.js.
We don't think this would be a breaking change for anyone ... and the remedy is simple enough: define it yourself at the top of your app.
We'll probably remove these lines for the next release unless we discover a reason to do otherwise.
F5 fail?
I can't repro this at all. I suspect your are conflating your discovery that breeze is inadvertently in the global namespace with your efforts to write an Angular app that uses breeze.savequeuing.js.
Why do I think this? Because the error you describe arises when trying to use breeze.savequeuing.js in an Angular app which is explicitly disallowed in the comments (line #14) of v.1.0.4:
Depends on Breeze (which it patches) and Q.js (not for use in Angular ... yet)
You no doubt omitted Q.js from your required libraries and it all goes to custard from there.
I'm personally allergic to the "save-when-user-changes-anything" user experience that made save queuing necessary. I'm almost sorry I wrote it. But there it is.
The apparently dependence on Q.js is the reason it isn't available for Angular apps as written. It's actually pretty easy to make it Angular-ready now because we recently (quietly) made accessible the component that Breeze is using for promises
breeze.Q // returns the promises component currently used by Breeze
Therefore, you could change the one reference to Q on line #104 to
var deferredSave = breeze.Q.defer();
This should work when using breeze v.1.4.14 and later. I haven't fully tested it yet.
This change (or something like it) likely will find its way into breeze.savequeuing.js v.1.1.0 (as I just pushed a non-release version of that).