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.
Related
Help me please.
i am working with next js, i need to make this structure in url sitename/catalog/category/group/product
category, group, product pages are created dynamically, after that I need to generate static pages with ready-filled html markup in the out folder via the 'next export' command. I want to get all category, group, product pages to make a completely static site. In the documentation, I did not find information about a large nesting. Please tell me how to do it. Here is my current structure and what next js generates for me
Is it possible to do this?
my file structure
pages
catalog
index.tsx
[category]
index.tsx
[group]
index.tsx
You need to create dynamic URL using [slug] for all dynamic variable in your URL component.
Check the documentation: https://nextjs.org/docs/routing/dynamic-routes
Once you use dynamic URL, you need to serve getStaticProps (for data as props) and getStaticPaths (for diff routes) method on page to serve the data.
Note: above method are only executed on build time, in case of next export also.
I have a multi-lingual application that I use exportPathMap but I want to transition to getStaticProps and getStaticPaths. My structure looks like so:
pages/[language]/[app-slug].js
However, [app-slug].js could be any of 20 different applications with unrelated code...
After reading caveats I thought, with pre-defining the getStaticPaths, I would be able to do:
-[language]
--[app1].js
--[app2].js
...
But it throws You cannot use different slug names for the same dynamic path ('app1' !== 'app2')
Is there any way to dynamically load the react app code based on path, or to have multiple dynamic files in one repo? (all static paths are known)
This similar answer to use query values won't work for my case, SEO and bundle size are top priorities.
I have four projects.
First, Its called Portal and have some logical components.
And the others manage other things.
Each of them has its own routes, but I would like to create a higher o superior routes to nav between all of them.
How can create that path to access to each project I dont have the component??
For example,
I want in one path have:
/portal
/login
/home
/error
/project1
/project2
/project3
This will be in portal, but in portal I dont have a Component called roject1.
<Route exact path="/project1" component={Project1} />
How can create that path to access to each project I dont have the component??
Or I should create it and make a redirect to Project1??
Thanks
Yes, but you should create separate folders. It is generally bad practice to leave different projects in a single folder.
You can directly call files to be used with import { functionName } from './directory';
(further explanation can be found here)
I have a group of images at my root level and I also have a page called Help. If I navigate to rootspace/Help angular knows to get the images from the root repository, but if I change it to rootspace/Help/ then angular thinks the files are in a folder 'Help' that doesn't exist. I need the extra slash because I want to put more information after it.
How can I maintain '/Help/' without angular thinking this is part of the path it needs to find resources?
How are you getting the images? I'd recommend creating a resouce, this way angular will always know where to find the images if you provide a base url. It will also be easy to configure later on if you change the location of the images.
Example code:
angular.module('resources', ['$resource'])
.factory('Images', function($resource) {
return $resource(baseUrlGoesHere + '/images', {}, {})
})
Then you can inject the resource into your controller and call Images.get()
BTW, you probably can't use the code as is, I think the injection of $resource will fail but I'm not sure.
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.