I have an Agular app with several lazy-loaded modules. These modules each contain some different components which are logically similar but differ in content. E.g. each module may have its own "home" component.
Is it okay to name these components exactly the same?
To me, it seems overly verbose to prefix each with the module name. Especially when the names start to get long, and considering I would like to maintain the balance between concision and readability.
Functionally this doesn't appear to be a problem. Take the following app as an example. It has 2 lazy loaded modules each containing 2 components with the same name as the components in the other module. One component is loaded by the module's route and the other is loaded via its selector in the template of the first component.
https://stackblitz.com/edit/angular-comp-name-test
I understand that this question may be considered as opinion-based but are there any technical reasons why this shouldn't be done? (I am also interested in opinions if someone wants to dm me)
Technically there is no issue, you can use the same name. Like I have many modules having dashboard as each respective module's component. As long as you properly import it, its fine.
But for larger apps sometimes when auto importing it can import pointing to different 1 then the one required. This happened with me once, I had add and list component in 2 different so while auto importing the url was pointing to the wrong one.
So for just the sake of clarity its nice if you keep different name like prefixing it with something so you know it is for this module etc otherwise we can't say it is or is not "good or bad practice".
Hey you can use import aliases in the tsconfig.json paths
"paths": {
"#modules": "app/test-mod(?:\.\d+)?"
},
You can use regex to match the file end names so that if you have more than one folder you can just name them like file1, file2, file3 and son on the match them in the import using
import('#modules/innerfolder/mymodule.ts')
I have been working on a project with 5 lazy loaded modules having millions of components in their sub folder with same components names.
The good reason or the problem faced by me in while in the development only is while importing the components the auto import does some time imports component from different module and that way I have been facing confusion and getting development done some time with wrong components.
But this has happened 2 times after then I was very safe while importing components
Related
I'm using storybook to be the showcase of different components. However I've found that the context of different components in storybook are not separated. E.g. in one of the story, I register the mocked services in the Dependency Injection, and in another story, I will get the already injected mocked services from the previous story.
I've also found that the CSS files being imported are also being kept in the memory. If there is some global CSS styles, once it is being imported in the first story, I could also get it in the second one without import it again.
However this is causing problems, e.g. the Dependency Injection library will complain that a service is being injected twice.
It seems that all the stories in the storybook shares the same global context. Is there any way to separate the context, so that each of the stories has its own context which is getting destroyed each time when people switch the story?
Please let me know if you need any extra information, e.g. storybook configuration or so.
Thanks in advance.
In my workplace I've been told by my supervisor to use autoloaders instead of using many import statements since it's slow! First of all, based on my research there are no performance benefits of doing so and secondly(I'm using js modules, and we are not talking about bundles), I can't think of any good reasons for doing such thing.
The way my imports work now are:
Imagine we import a.mjs like so ->
import '/js/components/a.mjs'
The route /js/ is a rule that redirects to my root of static js files, so I don't even need to use relative paths.
Is it bad practice? If there is something that I'm missing anything please tell me; I've done my research and didn't find any reasons to use autoloaders with js modules.
An actual example for you to see:
Flask route rule:
#app.route('/js/<path:filename>')
def js(filename):
return send_from_directory(Path(app.root_path).parent.absolute().joinpath("static\\js"), filename)
and in my js files:
import {View} from "/js/common.mjs";
import Spinner from "/js/components/spinner.mjs";
import RecommendedTripsSlider from "/js/components/recommended-trips-slider.mjs";
import TripsSlider from "/js/components/trips-slider.mjs";
import Blogs from "/js/components/blogs.mjs";
Thank you for your time. I appreciate it.
From the JavaScript Modules Guide on MDN :
Modules are only executed once, even if they have been referenced in multiple <script> tags.
This can be verified in the spec under section 16.2.1.5.2 Evaluate.
Evaluate creates and returns a Promise which resolves when the module has finished evaluating. This Promise is stored in the [[TopLevelCapability]] field of the [[CycleRoot]] for the component. Future invocations of Evaluate on any module in the component return the same Promise.
The first time the browser needs a module, it is hoisted, loaded, cached and executed. Additional import statements in future scripts will reference the pre-evaluated module from memory. No additional HTTP requests need to be made. No additional execution needs to happen.
On subsequent page views, the locally cached version of the module will be used, assuming your server's caching policy is configured appropriately, or you've implemented caching with a service-worker. In fact, you can even preload any specific modules that you might need ahead of time.
Performance-wise, as long as your app isn't importing hundreds of modules you should be fine. At that point you should probably look into bundling related components together with tree shaking. However, monolithic app bundles should be avoided as they obliterate the benefits gained from using modules since one small change to a single component means your users now have to re-fetch the entire app. Keeping your components split up means that user agents only download the parts needed to display the content on the page they're on and nothing more.
One reason you might want to use a module loader/bundler would be if you were installing dependencies through a package manager like npm. Then you would need a way to resolve the named imports to their actual file paths. But that process can easily be handled without a build step by using import-maps.
<script type="importmap">
{
"imports": {
"moment": "/node_modules/moment/src/moment.js",
"yourlib": "/lib/yourlib.js"
}
}
</script>
Unfortunately, this feature is not available in all browsers yet but. This already works in Chromium based browsers, has recently been implemented in Firefox (slated for release in v102) and support for other browsers can be polyfilled with es-module-shims.
This is the future of native module resolution. Implementing an autoloader into your project now would be a step backwards.
I created a angular library with angular 9 cli. What I noticed: I can only include modules by loading the whole library:
Of course this makes no sense in a real world application. I want to be able to load each module individually. What am I doing wrong? Why can't he find the image component under #devmonkeys/mark6/image
I linked the repository because I don't know exactly what it is. I think this makes more sense than posting the code of 6 possible files here.
What I mean exactly: #angular/material for example, each component has its own path to avoid loading the whole library into the app during build. https://material.angular.io/components/button/api as an component namend MatButton. to import it we must use: {MatButtonModule} from '#angular/material/button'; i also want this, because it makes no sense to load the whole libary in my code only because i want 1 component.
I' am looking for a way through which I can load multiple modules under same path in Angular. For example, consider I have three modules AModule, BModule and CModule each having its own RouterModule.forChild call. Now I want to mount all these modules under say site route.
One way I have achieved this thing is by wrapping routes in RouterModule.forChild call under site route as follows:
RouterModule.forChild([
{
path: 'site',
children: [{}] // children goes here
}
])
I don't know whether this approach is correct but it is working fine. The only issue which this approach is that I have to specify canActivate in every module I want to mount under site. While this is not a problem, I was looking for a cleaner solution.
I know there is a property loadChildren which could be used to load modules lazily. But I want to load modules eagerly.
I' am using AngularCLI which splits code of module I specify in loadChildren in a separate JavaScript file which is not I want.
I' am using AngularClI v1.2.0 and Angular v4.2.5.
Any help is highly appreciated.
Thanks
I'm not entirely clear on your goal and what you are ultimately trying to achieve, but here are a few thoughts.
You can use the loadChildren and "lazy loading" to load on demand OR eagerly. If you select eagerly loaded routes, as soon as your main route is loaded and your first view is displayed, the other modules marked for eager loading are immediately loaded asynchronously.
I have an example of that here: https://github.com/DeborahK/Angular-Routing in the APM-Final folder.
I'm not clear on why you don't want module splitting. It can significantly improve the startup performance (time to display of the first page) of your application.
In addition to canActivate there is also a canActivateChild so you can put this on the parent and not have to repeat it for each route. The docs for that are here: https://angular.io/api/router/CanActivateChild
New to Javascript/Backbone. I am wondering what's the 'convention' in Backbone when setting up directory structure.
I have a Backbone.js app that has two main 'entry' points. One is Admin (admin.mydomain.com), and other is User (user.mydomain.com). Now I am confused about how to name the files/directories.
In particular, is it better to do this:
-views
--admin
----items.js
--user
----items.js
-templates
--admin
----items.html
--user
----user.html
--models
--collections
or
-admin
--views
----item.js
--templates
----item.html
-user
--views
----item.js
--templates
----item.html
--models
--collections
Also, if I have a directory with 2 routers, and I don't want to create 2 seperate directories just to house 1 file in each just to seperate them, how should I name them? For example, I have a directory routers which contains two files, a router for admin, and router for user. Should I have:
2 seperate directories named user and admin within the directory router, and each directory contains router.js
just 2 files in router directory named admin-router.js and user-router.js.
Also, when is preffered to name a file admin.router.js or admin-router.js ?
Thanks!
This will probably get closed as "not a real question" or something similar, because it's a stylistic thing that, depending on your point of view, either doesn't have a correct answer or has a different correct answer for every project.
I'm a big fan of the second option, because it means that different people can work on different parts of the project independently. If you happen to write a utility package, it can be dropped into a different project easily rather than having to put three different files all into different places. And, by the same token, it's Bower-friendly, should that be appropriate for your use case.
The advantage of the first approach is that not everything will fit nicely into sections like that. What happens when you have models that both user and admin rely on? You're stuck with either duplicating code, having one with a hard dependency on the other just for that one file, or separating it out into its own module, which quickly deteriorates into a completely flat structure if taken to its logical conclusion.
The Google-friendly terms you're looking for are "package by feature" and "package by layer" if you want to learn more, or if you just enjoy reading Internet slapfights.