This declares an ES6 module:
<script type="module" src="animals.js"></script>
My problem is: this makes a 1-to-1 connection between a module and a source file.
I would like to split "animals.js" into "dogs.js" and "cats.js". Is this possible with ES6 modules?
I would like to define the module in this way:
<script type="module" name="animals" src="dogs.js" src="cat.js"></script>
ES modules are constraint to a single exporting context which happens to correlate to a single automatically created exporting context per file. So you can’t. You can however introduce a new module and it will be its own file/script block.
Alternatively, you can use a bundler that will accept several input files and produce a single ES module output file. Webpack might be a great choice.
Alternatively, you can introduce a module that imports and exports the contents of the other modules, serving as a kind of a wrapper or facade if you will.
Also, keep in mind that 1-to-1 connection between a script file and an ES module is inherent to the whole design of the ES modules, as well as many other bundling and namespacing systems. This is legitimately a feature and the need to have more than one source file per module might designate a flawed architectural design in your software.
If you would like a Java-like module behavior, you should definitely check out Typescript namespaces. Although, you will eventually realize how many different type inference caveats and parallel module visibility issues are there and thus will stop using them altogether in favor of ES2015 modules, they might be useful for just getting used to the modern technology.
Related
Is there a possibility disable SAP Spartacus I18next module in order to use my own translation module/strategy?
I'm trying to use my own shared module with translations but it is based on i18next library same as inspartacus/core, it seems like they are conflicting, because separately they work good.
It is possible but it would require a lot of work. I18nModule is a core part of the project and is imported in the StorefrontFoundationModule that is used in the in the StoreFrontModule and so on.
Therefore, to remove it would require to import all of the modules imported in the StorefrontFoundationModule, StoreFrontModule and B2cStorefrontModule. Directly to your AppModule. This is doable but the app is likely not to work.
Many components and services depend on translations so you would need to make sure your custom translation is provided in a way that it satisfies those dependencies.
Basically I am saying you are better of trying to extend or override the Spartacus translation functionalities to fit your use case. This module is configurable, extendable and powerful. Feel free too take a look at our documentation on the subject https://sap.github.io/cloud-commerce-spartacus-storefront-docs/i18n/#page-title.
Is everything in ES6 part of module.
eg. if I write in a file.
function simpleFunc(){
console.log("test")
}
Is this function not available to code in other places. In regular javascript , this function can also be executed from within html script.
What is the whole concept of modules. I understand polluting global namespace is a bad practice , but when we export a function or const, is it just an approach to avoid polluting global namespace. Can a developer still write var a= 10 in a js file and waste all the efforts of maintaining modules. I suppose this would still be possible because es6 is supposed to be backwards compatible with js.
Simply my question boils down to: Is a js file different when the language is ES6.
Not sure why no-one has answered this question yet, it's a simple answer, so I will answer it in case anyone else stumbles onto it:
Javascript is javascript.
ES5 practices still apply to ES6 in terms of script placement. Modularization allows you to import code from one script to another - this can help you keep large applications maintainable as well as many other structural benefits.
Additionally you are right about not polluting the global namespace - modules are also namespace containers, which protects the global namespace.
Here's a quote from a good (full) explanation to the importance of modules:
Modularization is the basic necessity for any software development. Breaking things into smaller pieces of functionality gives us the power to reuse the code. Modules are also containers for the namespaces.
I am building a module that exports a cmdlet that I would like to make available through my profile. The implementation of this cmdlet is spread across multiple implementation files that contain implementation functions I don't want to make publicly available. So I use Export-ModuleMember to hide them.
File get_something.psm1
import-module .\get_something_impl.psm1
function Get-Something {
[cmdletbinding()]
Get-SomethingImplementation
}
Export-ModuleMember -Function Get-Something
I then add get_something.psm1 to my profile. By exporting only Get-Something, all of my implementation functions remain "private".
The issue I'm experiencing is that when using the Export-ModuleMember command, I have to import a module in my implementation files every time I need a function inside of it. For example, assume I have a module, person.psm1, with a function, Get-Person, that I need to call throughout all of my implementation files. Now I must import person.psm1 in every single file that I need to call Get-Person. This is a result of using Export-ModuleMember-Function Get-Something. Without it, I would only need to import person.psm1 once and it would be available.
In essence, Export-ModuleMember is not only blocking my implementation to the outside. It's blocking it from my own implementation.
Is this expected and considered a normal aspect of designing PowerShell modules?
This was actually a bit of debate during the development of modules. Originally, Export-ModuleMember was required to export any function. This became tedious and limiting. So, by default, all functions from a module are visible, but variables and aliases are not, as long as you've never used Export-ModuleMember within the .PSM1.
If you use Export-ModuleMember, it begins to restrict that list. It may not be a bad idea to export a smaller number of functions, but you have to use it somewhat carefully.
You can either write:
Export-ModuleMember -Function a,b,c
which exports a few functions.
or
Export-ModuleMember -Function *
The latter one is equivalent to omitting Export-ModuleMember altogether.
You can use more restrictive wildcards if you'd like, but I find that 99% of the time, you don't need to bother with it at all.
The other thing you seem to be asking is how best to handle module dependencies. Nowadays, it's fairly common to import a module or two when writing a script, just like it's fairly common to include an assembly or two in a C# project. If you're doing this inside of a module, you can use the -Global flag on Import-Module, and avoid using -Force (which will reload the module). This makes it a notch more efficient to reuse the module in different functions. It also makes it less likely to have problems with "cycling" (unloading and reloading) the module, which, unfortunately, many modules do not do well.
The alternative to referencing the module in each function is using a module manifest (Get-Help New-ModuleManifest). Module manifests are very interesting, and required learning for many parts of module development. If you include a module in the RequiredModules list of the Module manifest, it will be automatically loaded before the module is imported (at least in PowerShell 3 and greater). If you include a module in the NestedModules list of the module manifest, it will be loaded as part of the module, and the commands exported by the module will be exported by your module instead.
Module design is a tricky beast, but it's very rewarding to do right. Best of luck.
I have designed a initial module lazy-loading system for a particular goal. In my special case there're a few modules that are needed to decorate forms and entities of the rest of the app.
However most of my members will only require a single one of them that will most likely never update. That is why I do not wish to load all of these modules in every request.
Now that worked like a charm until I required to provide extra view files from these modules. It appears like the module's
view_manager
config is not it merged into the
ViewManager
which is why the resolver is not capable to resolve the view file. I am now loading all these modules by default for testing -- it works.
My lazy loading mechanism bases on a
ModuleManager::loadModule()
call in case it is not it loaded already.
Do you know easy approach to properly inject/merge the config into the ViewManager? Also is this a general problem that possibly also affects other components? Or is it a error?
Thank you in advance!
I'm having trouble finding good advice and common practices for the use of namespaces in Clojure. I realize that namespaces are not the same as Java packages so I'm trying to tease out the conventions in Clojure, which seem surprisingly hard to determine.
I think I have a pretty good idea how to split functions into clj files and even roughly how I'd want to organize those files into directories. But beyond that I'm having trouble finding the mechanics for my dev environment. Some inter-related questions:
Do I use the same uniqueness conventions for Clojure namespaces as I would normally use for Java packages? [ie backwards-company-domain.project.subsystem]
Should I save my files in a directory structure that matches my namespaces? [ala Java]
If I have multiple namespaces, do I need to compile all of my code into a jar and add it to my classpath to make it accessible?
Should each namespace compile to one jar? Or should I create a single jar that contains clj code from many namespaces?
Thanks...
I guess it's ok if you think it helps, but many Clojure projects don't do so -- cf. Compojure (using a top-level compojure ns and various compojure.* ns's for specific functionality), Ring, Leiningen... Clojure itself uses clojure.* (and clojure.contrib.* for contrib libraries), but that's a special case, I suppose.
Yes! You absolutely must do so, or else Clojure won't be able to find your namespaces. Also note that you musn't use the underscore in namespace names or the hyphen in filenames and wherever you use a hyphen in a namespace name, you must use an underscore in the filename (so that the ns my.cool-project is defined in a file called cool_project.clj in a directory called my).
You need to make sure all your stuff is on the classpath, but it doesn't matter if it's in a jar, multiple jars, a mixture of jars and directories on the filesystem... As long as it obeys the correct naming conventions (your point no. 2) you should be fine.
However, do not compile things ahead-of-time if there's no particular reason to do so -- this may prevent your code from being portable across various versions of Clojure without providing any benefits besides a slightly improved loading time.
You'll still need to use AOT compilation sometimes, notably in some Java interop scenarios -- the documentation of the relevant functions / macros always mentions that. There are examples of things requiring AOT in clojure.contrib; I've never needed it, so I can't provide much in the way of details.
I'd say you should use jars for functional units of code. E.g. Compojure and Ring get packaged as single jars containing many namespaces which together compose the whole package. Also, clojure.contrib is notably packaged as a single jar with multiple unrelated libraries; but that again may be a special case.
On the other hand, a single jar containing all of your project's code together with its dependencies might occasionally be useful for deployment. Check out the Leiningen build tool and its 'uberjar' facility if you think that sort of thing may be useful to you.
Strictly speaking, not necessary, though many Java projects have dropped that convention as well, especially for internal projects or private APIs. Do avoid single-segment namespaces though, which would result in classfiles being generated in the default package.
Yes.
Regarding 3 & 4, packaging and AOT compilation are entirely orthogonal to the question of namespace conventions.