I'm new to Nuxt and Vue in general, so I'm not sure, what would be the best solution for this use case.
I want to change the text (like "Home", "Settings", "Favourites" etc.) inside my Header.vue (always fixed on top of the page) from another component. like Favourites.vue for example.
Sometimes I want to hide the header completely or hide the title and display buttons instead,
so I need to pass more props than just the title.
I tried using different layouts, but that breaks the animation transitions (I haven't found the solution for this yet), but I think it's still better to have control from the page in what I'm passing into this component.
Should I pass props from Page.vue to parent and read it from there in Header.vue component?
Should I use Vuex to pass this through the store and update it when the route changes? Or is that too complex for this use case?
Maybe there's a simpler solution that I'm not aware of.
Folder structure:
/components
├──Header.vue
└──Nav.vue
/pages
├──Index.vue
├──Profile.vue
├──Settings.vue
└──Favourites.vue
Vuex is the answer here— don’t worry about the 'simple' use case. As soon as you notice you’re creating data that other components may rely on (is the header visible on this page? Is the text different? etc) it’s a good idea to move into Vuex and maintain a single source of truth.
Your app may seem simple to begin with, but it’ll inevitably grow and at that point you’ll appreciate having a single source of truth vs. trying to pass things between components via props.
Nuxt also makes implementing Vuex very straight forward. No doubt you’re capable of pulling up the docs!
Related
<router-link> in my opinion takes more work to implement, since you can add $router.push to any element with an #click event.
What are the pros and cons of each approach? Is there any instance, where <router-link> can not be replaced by $router.push?
While router-link's handler does the same $router.push(), it also performs under the hood a handful of useful actions that you will have to implement by yourself to assure the navigation works as expected in every scenario. For example, it activates a "navigation guard" to check for the validity of the triggering event, catches any navigation errors, also, it is the implementation of active route detection and styling which may be a pain to implement in complex navigations (for ex. multilevel navigation menus) that is also simplified by the router-link implementation.
These are some of the pros that I could spot at a first glance at its source code. You can look at it for a more in depth comparison here
First of all is a tag like a tag in HTML so you can not use it inside your script tags. You can only use it inside tags. You have to give to attribute to router-link and you do not need to use click etc.
However, for bigger projects sometimes you need to redirect to another page after you submit a form, or anywhere you like to use redirection in your js. That's why there is $router.push, the $router object is vue-router object so you have all functions that vue-router serves you.
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.
I'm writing an app in Vue and I have a really hard time understanding the component hierarchy, namely the parent-child relationships and how to pass data around.
I have a view that contains a map which in turn has some navigation controls and options that are overlayed on top of the map. Now, I want these controls to manipulate the map WITHOUT having to nest the buttons inside the actual maps as it will cause severe display issues (for example, clicking on a zoom button falls through the button and also clicks the next element under it).
My app looks like this:
Mapview
Map
Controls
Options
Optionpanel1
Optionpanel2
...
Now, a HTML input element in Optionpanel1 needs to control something in the Map, which is not actually it's parent component. Also, some data from Map needs to be passed down to Optionpanel1 so it would know what to control. To make matters worse, something in Options also needs to pass something down to Optionpanel1, so, even though event bus would allow communication upwards, it would not solve that I need to pass data from parents to indirect children and also components that are not it's children.
I can actually pass the required property down the line if I nest the Options inside Map and pass it down with :myProp="prop" and then in Options, declare it in props and bind to Optionpanel1, where it is again declared as a prop. But as I mentioned earlier, nesting elements that I do not want to be nested in a visual sense causes massive issues like mouse click falling through. Do elements even need to be nested inside eachother in order to define parent-child relationship?
I would want components to exchange read-only data without Y being a child of X in the DOM. Also, even if nesting components like this would not cause visual issues, does it not seem very annoying to have to register and bind it in every component along the way?
I don't understand why is it so difficult to simply read something from another component. It's starting to seem that Vue is causing a problem that it's supposed to solve? Am I missing something here or am I looking at this in a completely wrong way?
Thanks in advance.
Basically you have 2 options to control complex components:
Handle the actions in your so-called "smart component" (in terms of React), which is the common ancestor for the controlling and controlled components. It's a pretty good solution for small components, but that's not the case.
To separate common logic and data in a Vuex store. I'd recommend you doing this.
I'm being using Vue.js for some months and it's have been reminding the webforms paradigm, that you used components to make a website or webapp, but with Vue.js it's a pleasure to create such things and not a whole nightmare it was with webforms.
Well, my question is if it's possible making nested components just to define some behavior on it's parent on a markup-way. Example:
<grid prop1="somevalue" prop2="somevalue">
<grid-column prop1="somevalue" prop2="somevalue">
<filter-options prop1="somevalue" prop2="somevalue">
</filter-options>
</grid-column>
</grid>
So, a particular grid component have column and the column hava a filter options.
Don't want to depend stricty to the javascript code.
Thanks in advance
EDIT: Just to add that the childs-component must not have a template. They are just to pass some props to the parent.
To answer your question
if it's possible making nested components just to define some behavior on it's parent on a markup-way
And to keep in mind your request:
Don't want to depend strictly to the JavaScript code.
The answer is no, it is not possible. Components underneath the parent can only push (emit) data to the parent after the DOM loads. So you would need to push a value that would trigger some JavaScript if you wanted to alter the html. Using JavaScript would be the only method though.
To achieve what you are asking I think it makes a lot more sense to use props on the parent component. You have a lot more flexibility and you can make it very versatile.
As the title implies, I need solid SEO and thus I need to have all the HTML loaded on my site on initial load. However, because the backend is written in PHP, and because it would be more work to write my Vue components with the server in mind, I don't want to use server-side rendering (SSR).
That leaves me with the option to send HTML over the wire, the "old school" way. What I am thinking of doing is writing each page's HTML like normal, but make one of the root html elements a Vue element in order to "upgrade" it. So the initial load downloads the finalized HTML, with all the data (tables, lists, etc already populated), but then after all the scripts are loaded, javascript can take over to make things easier and give a better UI experience. This poses a few questions, however:
Am I limited to a single component, the root? It'd be nice to still have many sub-components that would each have their own state. Perhaps inline templates can be used somehow?
Vue templates have their own templating system, like the mustache braces for displaying variables {{ myVar }}. Will I not be able to use them? The one way I can think of is to create a Vue template (that can be loaded from an external script) that is identical to the part of the HTML that it "takes over". The downside is that I'd have to maintain that component both in the original HTML and in the vue template.
Are there any good examples of what I'm trying to accomplish here?
Edit: I want to clarify that I'm aware I can put in various components here and there throughout the page. This still poses the question of how to make those components already start out rendered. Better yet would be to turn the whole page into Vue, much like an SPA.
I need solid SEO and thus I need to have all the HTML loaded on my site on initial load.
This is not entirely true. Google (80% of search traffic) easily parses SPAs now, so SSR purely for SEO isn't required anymore.
But to answer your question in general, you should check out Laracast's Vue.js series. They go in-depth on how to use PHP with Vue.js (including templating and variables).
I'd ask what it is you want to achieve with Javascript/Vue.js in your page. If everything is already rendered in PHP, does Vue provide a simple UX enhancement or takes over most of the page's heavy lifting (navigation, etc.)? If you have no reactive data and want Vue to simply be a controller for rendered components, then knock yourself out, although it might be approaching an 'overkill' scenario.
Have you looked into Prerender SPA Plugin ( https://github.com/chrisvfritz/prerender-spa-plugin )?
It is offered in the Vue documentation as a viable alternative to server side rendering ( https://v2.vuejs.org/v2/guide/ssr.html#SSR-vs-Prerendering )
Recently I've developed a multi-page application using Vue, here is how i tried to solve the SEO (Maybe this can help you ):
Htmls of header and footer (and other main common components) are packed to the page.html(eg: home.html, search.html).
Script and style are of header and footer imported in page.js(eg: home.js, search.js).
Add div.seo-zone to page.html's div#app, which includes the main SEO data(using some h1,h2,p,div and so on), and add
.seo-zone {
display: none;
}
in your css.
4. Make sure your app's root component's el is '#app'(each page's main content can be a Vue app).
Develop your app as usual.
After Vue rendered, the div.seo-zone will be replaced with your Vue components (although it can not be seen)