The Goal: Have two separate, independently navigateable routes with vue-router.
Details:
How can I have two parts of a page that are independently routed with vue router? Say you have a page split into a main view and a sidebar. The main view is what you would normally expect from a view, you click on links and it changes the path and loads a new component. The sidebar is completely separate, no matter where you are in the main view the sidebar does not change, but the sidebar also has links that let you go to different components within itself.
With vue-router, I can have named views, but these seem to be tied to whatever the current path/route is, and cannot be controlled separately.
Example Annotation:
Question
Can vue-router have two separate, and independent routes/views that are not tied to each other? If so, is there documentation on this, are there router code examples?
Note: There is no code here, it doesn't seem necessary as this isn't a code issue, it's a vue-router use-case issue.
You can achieve separate independent routes if you use 2 Vue apps each with its own router.
A small demo in this fiddle.
I've used 2 routes, one with history mode and one abstract.
The biggest problem I see with this is that, at least out of the box, you cannot have a URL that points the user to the same view(s), as now you are managing 2 different routers.
The other is related to communication, you now have 2 different Vue app instances so you need to do something about communication between them.
But this shouldn't be that hard
if you are using Vuex you can set the same store object on both of them
If you are just using a plain data object you can pass the same object to both instances and that will become reactive or
you can always communicate over the same bus
Related
I am about to create a Vue.js project and i use the smart/dumb pattern for my ui components. In my dumb components I have already the input, buttons and etc..., but in my smart components I am curios if it is really necessary to create a component if i will use that only in one page. For example. login-form component, then i will use that only in login page. So, ⤵️
My first question, is it really necessary to create a component for that ?
Second question, and when will i gonna create a smart components?
Moving code to another components makes code of initial component more readable. Even if you are going to use that new components only once.
Usually smart components - are pages that fetch or simply share some data to its children.
Lets say I have a website where I sell some sort of products. I'd have a Product.vue component which will be used to render all the products the user would see on the home screen.
I'd also need a second component that will be used to render the products on the admin panel, where the admin will be able to edit/delete.
Obviously both components will render a product, but they'll look different, have different functionality so I assume I can't make an all-mighty universal component for that, so I'd need 2 different components.
Now I'm really confused how to name my components. Currently I have the following folder structure:
Components
---Admin
------Product.vue
---Product.vue
So in the components folder I have a Product.vue and the Admin folder, which contains the admin Product.vue. I'm wondering if having 2 components with the same name in different folder is a bad practice?
The second alternative is calling the admin product AdminProduct.vue
Two components with the same name in the single app is never a good idea from maintainer point of view.
Lot of useful info can be gained from Vue Style Guide
Multi-word component names
Component names should always be multi-word, except for root App components, and built-in components provided by Vue, such as <transition> or <component>.
This prevents conflicts with existing and future HTML elements, since all HTML elements are a single word.
Tightly coupled component names
Child components that are tightly coupled with their parent should include the parent component name as a prefix. If a component only makes sense in the context of a single parent component, that relationship should be evident in its name.
So AdminProduct.vue is fine...
And instead of Product.vue it should be a ProductView.vue
Vue has an object hierarchy and beyond that it can render even multiple instances of the same component. So object-wise you're good.
Regarding the file names, I don't see big risks in it because one of the Product.vue files is clearly in the Admin folder and the other is not. However if this is a project that will be worked on by multiple developers, it might be wiser to name them differently. Not because git can't deal with directory structures, but because humans can make errors. At least I do it all the time.
I would like to ask when do you use dynamic components instead of vue router? Is it good to use dynamic components instead of vue router? I'm referring more to child routes. Let's say we have an app and we have several nav elements. For instance 'About', 'Cases', 'Services', 'Contact' and if we go to each of them there are a few more options displayed. Let's say if we go to 'About' then we have 'Team', 'What we do', 'Our mission' something like that displayed in that page. Other ones have extra links inside as well. So these could be used as child nav or could be loaded as a dynamic component. What would be advantages and disadvantages to use one over another?
With routing you can link to pages easily and refresh them. As dynamic components linking to them would be more difficult and refreshing would revert the component to default state.
In your case I would use routing but you have to weigh the usefulness case by case. Would someone want to link to yourpage/about/team? You can also consider fitting them all to single page and using anchors yourpage/about#team. I imagine crawlers won't be able to access views behind button clicks either, only links.
I am not pretty sure if in web development this kind of thing is called as a 'bookmark' layout. I'll explain on below screen.
I would like to achieve something like this and missing a knowledge of how to do that. Could someone point me where should I anchore ? I could not find anything in web / probably looking with using bad phrases.
This component would be part of the application, after we push to the router path it's going to display this kind of layout. Basically I could achieve this buy keep pushing a different route for each page, but what if those pages belongs to "one model comoponent" I wouldn't like to reload them all of the time while switching them, just once after we entry to each. It would work like a tab bar in mobile apps (iOS).
In many UI contexts (e.g. browsers, macOS applications, etc.) and in Web Development, what you refer to as "bookmark layout" is simply called tabs (like the iOS tab bar that you also mention).
I wouldn't like to reload them all of the time while switching them
Vue offers you the built-in component <keep-alive> for such use case:
When wrapped around a dynamic component, <keep-alive> caches the inactive component instances without destroying them.
See the Vue guide: https://v2.vuejs.org/v2/guide/components-dynamic-async.html#keep-alive-with-Dynamic-Components
When switching between these components though, you’ll sometimes want to maintain their state or avoid re-rendering for performance reasons. […]
To solve this problem, we can wrap our dynamic component with a <keep-alive> element
I have been doing some initial work to get to grips with the Aurelia framework and am trying to decide if I should be using child routers. This doesn't seem to be covered in much detail on the Aurelia router configuration page.
I was wondering if anyone has come across any good use case scenarios that I could examine to get a better understand of where and when to use this feature.
One scenario that springs to mind is 2nd level navigation. Say, for example, you have a main router for the top level sections of your app, eg:
Home
Products
Those sections could have a child router to handle the 2nd level pages - eg:
Products
Aircraft
Bombs
Guns
Tanks
Having the sub-views (aircraft, bombs, etc) for the products view in their own child router allows you to easily build out 2nd level navigation.