We Keep Coding

Get root url with subdirectories in Angular

So I have this application with multiple libraries installed on them, each with their own api. I want to retrieve the url for every library that will look something like http://hostname.com/subdir1/subdir2/exampleRoute without the route ('exampleRoute') because subdir 2 is my root folder, and add /libraryname after it so it will look something like http://hostname.com/subdir1/subdir2/libraryname. The amount of subdirs are not fixed, could be more, so if I have 3 subdirs, my root url would be http://hostname.com/subdir1/subdir2/subdir3.
I used to do this with window.location.href in the root component of my routes, and manually cut the last segment off but this is not the best solution, as I have to be able to get these urls in components that do have a route.

Your can easily use
document.head.baseURI to get what you want.

Next.js dynamic routes using a different URL

I am currently updating a React project to use Next.js. I've stumbled on a slight issue with Dynamic Routing which so far I can't find any solutions online.
I have a number of info pages that use the same component and display different content based on the slug. Using react-router these can be specified as follows:
path: /:infoPage(about-us|terms|privacy|contact|faqs)
/about-us, /terms, /privacy, /contact, /faqs
So far for Next.js, I thought I'd use a dynamic route as seen below. The only issue is that the URLs will now have /infoPage/___ - /infoPage/about-us, /infoPage/terms.
/pages
/infoPage
/[infoPage].js
As a solution links can be updated using as with the proper URL:
<Link href="/infoPage/[infoPage]?infoPage=about-us" as="/about-us">
<a>About Us</a>
</Link>
Whilst this works when clicking on a link, refreshing the page will end up a 404 page - since Next.js is not aware of any page as /about-us.
Possible Solutions
Use dynamic route /pages/[infoPages].js. Not quite sure if this is the ideal solution as it would most probably act like a fallback to any other page.
I suppose I could have every page declared separately within /pages and import the same component in each page but it will be slightly repetitive.
/pages
/about-us.js
/terms.js
...
Keep /infoPage/[infoPage].js route, add redirects from client/server to the proper URL
I may be over thinking this, the second solution would not be the end of the world but I'm still wondering if there's a better solution.
Thanks in advance :)

In case someone is looking for an answer to this question, here are two solutions you may consider.
1. Dynamic Route in /pages at root level
Use Case: Pages using the same components with similar data (for example API call to get page content)
If you have certain pages similar to each other at root level, you can create a dynamic route such as below:
/pages
/[rootPage].js
Keep in mind that if these pages are using Static Site Generation, slugs need to declared using getStaticPaths.
Further details on getStaticPaths here
It is also important to note that predefined routes take precedence over dynamic routes. Should a dynamic route have a slug the same as a predefined route, Next will always render the predefined route. So this approach can be risky at root level.
Dynamic Routing Caveats
2. Separate routes, one getStaticProps function
Use Case: Pages require similar data/API calls but use different components
You may opt to have routes for each page but use the same getStaticProps function.
Routes:
/pages
/about-us.js
/terms.js
getStaticProps helper function:
const getPageStaticProps = () => {
return async (context) => {
// generic logic here
}
}
Page (about-us.js, terms.js):
// /pages/about-us.js
function AboutPage(props) {
return <AboutComponent {...props} />
}
export const getStaticProps = getPageStaticProps()
---
// /pages/terms.js
function TermsPage(props) {
return <TermsComponent {...props} />
}
export const getStaticProps = getPageStaticProps()
This can also be implemented using getServerSideProps.
I opted for the second solution as it felt safer and still benefitted from having code shared between different pages. Obviously there may be other solutions our there that can be used :)

Angular lazy loaded module components with the same name

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

Is it possible to reload the router in a running ember.js app in order to update the path strings of routes?

I'm implementing multi-language support in my app, and I guess this is the last thing that I would need in order to be able to change between languages without reloading the whole app/page. (I already have a solution with full page reload.)
For a simple example let's say this is how my router looks:
Router.map(function() {
this.route('search', { path: t('search') });
this.route('item', { path: `${t('item')}/:id`);
});
The t function would be getting the correct translation for the given strings in the currently active language.
The structure of the route hierarchy won't change, the only things that need to be updated are the path strings. Application state should be kept, of course.
I'm wondering whether this is possible to do.

I am not %100 sure about the correctness of what I wrote but Router.map is executed and resources with the definitions given within this method is transformed to a DSL instance and that is then passed to the actual router maintained by Ember.Router itself. In order to achieve what you want I believe what we need is dynamic modification to the router even if it is just the paths you need yo modify not the whole route structure.
If you look at the following github issue, Ember.js no more supports dynamically adding routes (hence no dynamic modification to the existing ones I believe). With all that said, I believe what you want is not possible without reloading the whole app (hence losing the application state).

Backbone.js directory structure

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.