I have a huge list of permissions, and I'm only interested in importing three of them. I'm also interested in grouping them in an object and assigning a variable to that object.
Can I do any better than the following?
import {
firstPermission,
secondPermission,
thirdPermission,
} from '#constants/permissions';
const relevantPermissions = { firstPermission, secondPermission, thirdPermission };
I was inclined to try using the as keyword in the import step, but I couldn't get any such thing to work.
(This feels like an ignorant question; please forgive.)
as keyword is intended to import named exports under different names, not group them.
The code listed in the question is the way this should be done. If relevantPermissions is supposed to be used in multiple places, it's beneficial to re-export them:
export {
firstPermission,
secondPermission,
thirdPermission,
} from '#constants/permissions';
...
import * as relevantPermissions from './relevant-permissions';
This way named imports have a chance to be tree-shaken if some of them remain unused, also may get other benefits of ES modules such as improved code completion in IDEs.
Related
The directory each of our components live in will also be joined with multiple json files (these are translation files used for internationalizing our app). I'm trying to achieve something where I only import the translation file that needs to be used (depending on the locale provided) and not import all the others. Just playing around with this, I found several approaches that didn't work, such as:
const paths = {
"en-US": "#alias/components/Prefs/Component/lang/en-compiled.json",
"pt-BR": "#alias/components/Prefs/Component/lang/pt-br-compiled.json"
};
const Billing = ({ account_id, intl }) => {
const localeContext = useContext(LocaleContext);
import(paths[localeContext.locale]).then(module => {
console.log(module);
});
...
Here I was just trying to log out the contents of the json file to see if it was even being reached. However, I kept getting errors like so:
And I received the same errors for similar approaches. However, the one approach that did output my json contents, though seemingly the same, was just this:
import(
"#alias/components/Prefs/Component/lang/en-compiled.json"
).then(module => console.log(module.default));
What on earth is the difference between the two? Why does strictly placing the string in my import statement work, while referencing the string from a dictionary does not? If the first approach would work, it would be easy to import exactly what I need, but it's not seeming to get along with me.
I found some import statements of my .ts files in ionic projects are written as:
import { Component } from '#angular/core'
instead of
import { Component } from '#angular/core';
,which misses a semicolon, and the projects seems run normally, is the import statement need a semicolon at the end actually?
Javascript only requires semicolons to separate statements in the same line. However I'd recommend you to stick to the good practices and use them.
From the style guide for typescript
Use semicolons:
Reasons:
Explicit semicolons helps language formatting tools give consistent results. Missing ASI (automatic semicolon insertion) can trip new devs e.g.
foo() (function(){})
will be a single statement (not two).
I understand that ultimately this is a matter of style, as you shouldn't have any issues if you don't use them when they are not strictly required, although in order to be consistent, it's better to use them than not.
This is a pretty good article also. https://www.codecademy.com/blog/78
Hope this helps!
OP is asking about if semicolons are required in an import statement.
Use semi colons when declaring variables, returning something or making variable calls, as you are declaring a variable with the import it is my understanding that you should use a semicolon.
In perl, sometimes it is necessary to specify the function name in the use statement.
For example:
use Data::DPath ('dpath');
will work but
use Data::DPath;
won't.
Other modules don't need the function names specified, for example:
use WWW::Mechanize;
Why?
Each module chooses what functions it exports by default. Some choose to export no functions by default at all, you have to ask for them. There's a few good reasons to do this, and one bad one.
If you're a class like WWW::Mechanize, then you don't need to export any functions. Everything is a class or object method. my $mech = WWW::Mechanize->new.
If you're a pragma like strict then there are no functions nor methods, it does its work simply by being loaded.
Some modules export waaay too many functions by default. An example is Test::Deep which exports...
all any array array_each arrayelementsonly arraylength arraylengthonly bag blessed bool cmp_bag cmp_deeply cmp_methods cmp_set code eq_deeply hash
hash_each hashkeys hashkeysonly ignore Isa isa listmethods methods noclass
none noneof num obj_isa re reftype regexpmatches regexponly regexpref
regexprefonly scalarrefonly scalref set shallow str subbagof subhashof
subsetof superbagof superhashof supersetof useclass
The problem comes when another module tries to export the same functions, or if you write a function with the same name. Then they clash and you get mysterious warnings.
$ cat ~/tmp/test.plx
use Test::Deep;
use List::Util qw(all);
$ perl -w ~/tmp/test.plx
Subroutine main::all redefined at /Users/schwern/perl5/perlbrew/perls/perl-5.20.2/lib/5.20.2/Exporter.pm line 66.
at /Users/schwern/tmp/test.plx line 2.
Prototype mismatch: sub main::all: none vs (&#) at /Users/schwern/perl5/perlbrew/perls/perl-5.20.2/lib/5.20.2/Exporter.pm line 66.
at /Users/schwern/tmp/test.plx line 2.
For this reason, exporting lots of functions is discouraged. For example, the Exporter documentation advises...
Do not export method names!
Do not export anything else by default without a good reason!
Exports pollute the namespace of the module user. If you must export try to use #EXPORT_OK in preference to #EXPORT and avoid short or common symbol names to reduce the risk of name clashes.
Unfortunately, some modules take this too far. Data::DPath is a good example. It has a really clear main function, dpath(), which it should export by default. Otherwise it's basically useless.
You can always turn off exporting with use Some::Module ();.
The reason is that some modules simply contain functions in them and they may or may not have chosen to export them by default, and that means they may need to be explicitly imported by the script to access directly or use a fully qualified name to access them. For example:
# in some script
use SomeModule;
# ...
SomeModule::some_function(...);
or
use SomeModule ('some_function');
# ...
some_function(...);
This can be the case if the module was not intended to be used in an object-oriented way, i.e. where no classes have been defined and lines such as my $obj = SomeModule->new() wouldn't work.
If the module has defined content in the EXPORT_OK array, it means that the client code will only get access to it if it "asks for it", rather than "automatically" when it's actually present in the EXPORT array.
Some modules automatically export their content by means of the #EXPORT array. This question and the Exporter docs have more detail on this.
Without you actually posting an MCVE, it's difficult to know what you've done in your Funcs.pm module that may be allowing you to import everything without using EXPORT and EXPORT_OK arrays. Perhaps you did not include the package Funcs; line in your module, as #JonathanLeffler suggested in the comments. Perhaps you did something else. Perl is one of those languages where people pride themselves in the TMTOWTDI mantra, often to a detrimental/counter-productive level, IMHO.
The 2nd example you presented is very different and fairly straightforward. When you have something like:
use WWW::Mechanize;
my $mech = new WWW::Mechanize;
$mech->get("http://www.google.com");
you're simply instantiating an object of type WWW::Mechanize and calling an instance method, called get, on it. There's no need to import an object's methods because the methods are part of the object itself. Modules looking to have an OOP approach are not meant to export anything. They're different situations.
I have created a simple parser package called parseLine.
I have it in a package in my project.
In parseLine I have a class called "myParse".
I can import it just fine.
import parseLine.myParse.*;
But when I compile I get an error "1172:Definition parseLine.myParse could not be found.".
This is pretty basic I know but would appreciate any help anyone my be able to offer.
myParse is not a package, it is a class, so you are importing it incorrectly.
Basic structure of a package:
src / my / package / name / ClassName
To import ClassName, you would use this:
import my.package.name.ClassName;
or
import my.package.name.*;
In ClassName, it must have the following setup:
package my.package.name {
public class ClassName {
// class code goes here
}
}
As an additional tip, you should follow standard naming schemes for AS3.
Package names should be all lowercase. Even if it is multiple words. my.packagename is proper, whereas my.packageName is not.
Class names should be UppercaseCamelcase. So ClassName is proper, whereas className and classname are not
All objects, including functions, should be lowercaseCamelcase. So var someObject is proper, whereas var SomeObject is not (same for function doSomething() vs function DoSomething())
Constants should be UPPERCASE_UNDERSCORE_SEPARATED. So const SOME_CONSTANT_VALUE is proper, whereas const someConstantValue is not.
Not using those rules won't break anything, but they are the accepted standards in AS3 which makes your code easier to read and maintain in the future.
I develop a lot of frameworks for Flash games and applications. I have always prefixed my class names with a random character or two, to avoid conflict with class names that the developer may already have, for example:
class LEntity
Recently I had a co-worker blast me for poor and "annoying" naming of classes who then proceeded to rename every class in the frameworks I've created for people here to use.
I'm having trouble explaining my reasoning thoroughly enough for him to accept what I've done as a good approach.
Is what I've done above actually a bad thing? If not, how can I explain otherwise? If so, why?
Comments are asking about namespaces - I know AS3 in this example has what I know to be called a namespace but I'm not sure if this is the same thing or if it can be used as expected.
Given that Actionscript supports namespaces, there is no reason to use prefixes simply to prevent naming clashes. That's what namespaces are for.
Some people like to use namespaces to significy member variables (ie, underscore prefix, or sometimes m_) and that has some merit, but simply for the sake of name clashing no.
It sounds like you don't quite understand what namespacespackages are in AS3.
An example:
//Class1.as
package com.test.someModule { //This is the package/namespace
public class Class1 {...}
}
//Class2.as
package com.test.otherModule {
import com.test.someModule.Class1; //Class1 can be used as "Class1" now. Otherwise you would do "com.test.someModule.Class1"
import com.test.someModule.*; //You can also use the "*" to "import" all classes in that package
}
I have to agree with your co-worker, your class names are 'annoying'.
In Actionscript 3 we use the package name to define the namespace of a class. If you're not sure what namespace means, take the wikipedia definition (as of the time of writing):
"In general, a namespace is a container for a set of identifiers
(names), and allows the disambiguation of homonym identifiers residing
in different namespaces."
So you will never "conflict with class names" as long as you name your packages correctly. Most developers use what is called the reverse domain notation to name their packages (e.g com.mywebsite.MyGenericNamedClass). Domain names are unique so it's very unlikely you would clash with another class.
As a rule of thumb the class name should be as descriptive as possible, so some of your class names will be the same as someone else's class. Take the default Sprite class for instance:
import flash.display.Sprite;
import uk.co.mywebsite.Sprite;
if you then initialize an object:
var mySprite:Sprite = new Sprite();
The compiler would not know which Sprite you want to initialize (is it the flash sprite or your own custom sprite), and it would throw an error.
The solution is simple: because your packages have been named properly, all you need to do is to use the full class name including the package name to initialize your object:
var mySprite:uk.co.mywebsite.Sprite = new uk.co.mywebsite.Sprite();
var myOtherSprite:flash.display.Sprite = new flash.display.Sprite();
Mind you, you would rarely need to do that. This is only necessary if you want to use those two classes (the default Sprite and your own Sprite) in the same scope. Generally, you would only import your own class:
/* we are not importing this any more
import flash.display.Sprite;*/
//only importing my own class
import uk.co.mywebsite.Sprite;
/* now I can initialize my object without using the full class name, and the compiler knows
I mean my own Sprite class */
var mySprite:Sprite = new Sprite();