Develop Reference

Sails: Exclude directory from being auto loaded as helper

I am building a Sails.js application using sails 1.2.3, node 10.15. I want to include a javascript module in my api/helpers/* directory, without sails automatically using it to try to create a helper. I.e. I have javascript objects that use helpers and are used in a helper, but are not helpers themselves; as in this image, where the module 'rules' is imported into the create-rule helper and the objects exported by this module are used within the helper.
By default, sails tries to load each file in the helpers/* directory as a helper, and throws if the underlying implementation does not match that of a valid helper:
ImplementationError: Failed to load helper `create-rule/rules/foo/index` into a Callable! Sorry, could not interpret "index" because its underlying implementation has a problem:
------------------------------------------------------
• Missing the `fn` property.
------------------------------------------------------
Hoping someone can help out! Let me know if more info is needed. Thanks in advance!

I don't quite understand what you are trying to do. In my humble opinion I would grab all object constructors and placed them as a single file in api/services. That will make it automatically available in all controllers. I would not allow my object's methods to use helpers by them selves (I even think you can't, at least easily). Then when you need a helper to use your object, just pass it as parameter. Anyway, again, in my humble opinion; you are structuring your code to fit all inside /helpers and that will make it extremely hard to develop. Let assume you manage to make it work all inside /helpers, only you without exception, will be able to understand what it does or how it works. Doesn't seem as a good idea.

How to use i18n-iso-countries in React?

I'm working on a React app and trying to use the i18n-iso-countries package to get a countries object in English which has keys as iso codes and values as the country names. This is easy in node, as I've verified with a simple script running the way the i18n-iso-countries npm docs show, like this:
const countries = require("i18n-iso-countries");
console.log(countries.getNames('en'));
But when I do this in my react app (made with create-react-app) like this ...
import countries from "i18n-iso-countries";
console.log(countries.getNames('en'));
...I get an empty object back. When I log just countries (console.log(countries)) in React, I see the function "getNames" on it and the other functions the docs mention, so I'm not sure what gives.

Just needed to add this line!
countries.registerLocale(require("i18n-iso-countries/langs/en.json"));
Not sure why this needs to be added in React (and Angular - where I found answer How to use i18n-iso-countries in Angular 6 - and probably other ui libraries/frameworks) so if someone could explain that, that would be cool, but hey, at least it's working!

It is a little bit to late. But to answer jupiterjelly this line is needed for browser environment, so that your bundler knows that it needs to put this file in the bundle

dynamically load modules in Meteor node.js

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.

Enabling feature flags in Ember AppKit app at runtime

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.

Meteor modify auth smart package

How do I modify the auth smart package?
For example the dropdown box after registering show the buttons change password and sign out. I want to add an edit account button. How?
Thanks.

To add an edit button, look here:
https://github.com/meteor/meteor/tree/master/packages/accounts-ui-unstyled
Specifically, the login_buttons.html file.
update: There's a note at the top of the linked file:
NOTE: You shouldn't use these templates directly. Instead, use the
global {{loginButtons}} template.
Thus, you should find these files in your meteor installation (mine is in C:\Program Files (x86)\Meteor\packages\accounts-ui\login_buttons.html) and edit that file.
Note this will modify the accounts UI for all your meteor apps. If you do not want your changes to affect your other meteor apps, you will probably have to "fork" your own accounts-ui package.
There is discussion of making the accounts UI more customizable (like overridable templates), but it is not possible with the current version of Meteor. I suggest describing your use case to the meteor developers. The meteor developers openly welcome feedback:
Feedback, please! Some specific areas that we're curious about:
What sort of customization do you want to do to the loginButtons template?
What sort of account restrictions are you likely to use? Everyone must have a username? Everyone must have an email?

You can override the loginButtons, because currently the default helpers object is public for some reason:
Handlebars._default_helpers["loginButtons"] = function(options) {
return "hello this is test";
};
The original helper function looks like this:
Handlebars.registerHelper(
"loginButtons",
function (options) {
if (options.hash.align === "right")
return new Handlebars.SafeString(Template._loginButtons({align: "right"}));
else
return new Handlebars.SafeString(Template._loginButtons({align: "left"}));
});
Here you could replace the default _loginButtons template with your own.
However this could easily break with a future version of meteor as Handlebars._default_helpers is not really intended to be used in that way. But at least you don't have to work with a fork of meteor.
Also you have to make sure that you add your helper after accounts-ui-unstyled does. So if you are using this trick inside another package, be sure to declare accounts-ui-unstyled as a dependency.