Versions:
VueJS: 3.x
Chrome: Version 93.0.4577.63 (Official Build) (x86_64)
macOS: Big Sur 11.5.2
My use-case must be common, and I am mildly surprised that it does not work "out of the box".
I have these simple routes:
/patients/new
/patients/1
/about
which I access from a single-page application (SPA) through vueJS router-links:
<router-link to="/about">About</router-link> |
<router-link to="/patients/new">New Patient</router-link> |
<router-link to="/patients/1">Update Patient</router-link>
/patients/1 returns a pre-populated HTML FORM with details of patient with ID 1.
/patients/new returns the same HTML FORM with blank entries.
Intuitively, if I visit /patients/1 link, and then visit /patients/new, I would expect HTML FORM to be empty; conversely, if I visit /patients/new and then /patients/1, I would expect the HTML FORM to be pre-populated accordingly.
This is not what happens. Instead, the SPA does not re-create / re-mount the HTML FORM.
Solution: many articles suggest using a reactive variable referenced by a :key attribute in the HTML FORM. Then whichever link we visit, as long as we change the reactive variable, the vueJS component that houses the HTML FORM should be re-created / re-mounted.
My approach: provide a reactive variable at the root component, and inject it within the vueJS component (ie, the Patient component here) that renders the HTML FORM.
Here's what my root component looks like:
<script lang="ts">
import { defineComponent } from 'vue'
import Vue from 'vue'
export default defineComponent({
name: "App",
provide() {
return {
routePath: Vue.computed(() => this.$route.path)
}
}
});
</script>
where the reactive variable is routePath. Then in the Patient component, I have this:
export default defineComponent({
name: "Patient",
inject: ['routePath'],
...
});
with the HTML FORM defined with the :key attribute like this:
<template>
<form :key="routePath">
...
</form>
</template>
I believe the basic idea here is sound, but it is not working, and it does seem like a cumbersome approach.
So, here are my questions:
Is this approach sound?
Why is the Vue.computed() invocation broken? Here's the stack trace from Chrome console:
App.vue?3acc:9 Uncaught TypeError: Cannot read properties of undefined (reading 'computed')
at Proxy.provide (App.vue?3acc:9)
at qe (runtime-core.esm-bundler.js:2463)
at Pr (runtime-core.esm-bundler.js:6713)
at Lr (runtime-core.esm-bundler.js:6632)
at Tr (runtime-core.esm-bundler.js:6562)
at D (runtime-core.esm-bundler.js:4421)
at N (runtime-core.esm-bundler.js:4396)
at m (runtime-core.esm-bundler.js:3991)
at K (runtime-core.esm-bundler.js:5140)
at mount (runtime-core.esm-bundler.js:3477)
Thanks for looking into it.
It appears this issue is unresolved in vueJS 3.x. See open issue for details. There are work-arounds. Eg, see this github project. In my case, I've decided to change the workflow to avoid said issue.
Related
I am trying to programmatically route to a detail page from within a list in Nuuxt3 app:
#/pages/items/index.vue
<script setup lang="ts">
const gotoDetail = async (itemId) => {
await navigateTo(`/items/${itemId}`)
}
</script>
<template>
<div>
<NuxtLayout name="main-standard">
<template #main-content>
<div v-for='item in items' :key=item>
<div #click='gotoDetail(item.id)'
</div>
</template>
<template #main-content>
<!-- aside content -->
</template>
<NuxtLayout>
</div>
</template>
And I am getting this error message:
ERROR: Uncaught (in promise) TypeError: Cannot read properties of null (reading 'parentNode')
I have searched for an answer and most solutions mention to wrap the <NuxtLayout> with a div. But that did'nt solve my issue.
I am using a default Layout. So the<NuxtLayout name="main-standard"> is inside this default layout. Both pages: index.vue and [itemId].vue are in the pages/items/ folder.
I am doing something wrong but just can't find it. Does anyone see whats going on?
A few things here are going to break your code.
One, the middle div with the click handler is missing a closing >, contents, and a closing </div>. (Of course you may have omitted that for brevity)
items isn't defined, so there's nothing to iterate over.
You're using the same v-slot name #main-content for multiple templates, but each slot name should be unique. The # attributes (shorthand for v-slot) should match the slot names you write in your layout, and those must also be unique within the component.
The main problem looks to be related to the way you're using layouts. To mess with layout on a page using the component, you have to add this into the setup script:
definePageMeta({
layout: false,
});
A different way of applying your custom layout to this page is to replace the false boolean with the name of the layout, and omit the tag from this page altogether. For that to work, app.vue should have a <NuxtLayout> tag wrapping the <NuxtPage>
Not a breaking change, but it may also simplify things to write
<NuxtLink :to="`/items/${itemId}`">{{ whatever you wanted inside that div }} </NuxtLink>
If you need to run code before navigating to that page, you can add it into the top-level middleware folder, and call that named middleware on the page before which you want it to run.
Hello nice people of Internet ;)
New job, new language. I need to modify Ipyvuetify Vue code in Jupiter notebooks to use static props.
I was able to throw together simple vue example
where I am able to set prop of child component via assigned static text in declarative way in vue file.
And it works just fine in js variant. https://jsfiddle.net/wu9bxL1n/1/
But the same approach doesn't seem to work at all in ipyvuetify syntax. No error no nothing. Static string assigned to child prop is just being silently ignored and I can't seem to find anything in docs as for why. What did I missed ?
Here is the smallest possible code in ipyvuetify syntax copy/pastable to Jupiter notebook.
import ipyvuetify as v
import traitlets
class AA(v.VuetifyTemplate):
template = traitlets.Unicode('''
<template>
<v-card-title>{{label}}</v-card-title>
</template>
<script> export default { name: "aa", props: ['label'] } </script>''').tag(sync=True)
label = traitlets.Unicode('But this is showing default text instead').tag(sync=True)
class BB(v.VuetifyTemplate):
template = traitlets.Unicode('''
<template>
<div>
<v-text-field label="This text was set statically" ></v-text-field>
<aa label="This text was set statically"></aa>
</div>
</template>''').tag(sync=True)
components = traitlets.Dict(default_value={'aa': AA()}).tag(sync=True, **v.VuetifyTemplate.class_component_serialization)
BB()
---
Output:
This text was set statically
But this is showing default text instead
O boy.
Answer was some undocumented behavior seen in some 3rd party lib source code.
we need to use
default_value={'aa': AA }
instead of
default_value={'aa': AA()}
then setting static props to your own components will work.
Weird I know.
Hopefully people solving the some problem will find this.
Take care guys ;)
I'm trying to set up a .NET core project using Razor Pages and include vueJs inside the razor page for all my logic.
Something like this:
#{
ViewData["Title"] = "VueJs With Razor";
}
<h2>#ViewData["Title"].</h2>
<div id="app">
<span>{{ message }}</span>
</div>
<script>
new Vue({
el: '#app',
data: {
message : 'Hello vue.js'
}
})
</script>
I have read that mixing Vue and Razor pages is a bad practice, and one should use Razor OR Vue.
Why is this?
Mixing VueJs and Razor Pages is not necessarily a bad thing, it can be great!
I use Vue with razor for non SPA pages and the two work well together. I choose to use Vue by loading it via a script tag from a CDN and and I do not leverage the use of WebPack for transpiling, I simply write my code in (gasp) ES5. I chose this approach for the following reasons.
Using Razor pages rather than a SPA aids in SEO and search engine ranking of public facing pages.
Loading Vue directly from a CDN eliminates a whole stack of Webpack centric technology from the learning curve which makes it much easier for new devs to get up to speed on the system.
The approach still provides the reactive goodness to UI development that Vue inherently brings to the table.
By keeping with the “page model” the code that delivers site functionality is logically grouped around the backend page that delivers that functionality.
Since Vue and Razor can do many of the same things, my goal for public facing pages is to use Razor to generate as close to the final html as possible, and to use Vue to add the reactiveness to the page. This delivers great SEO benefits for crawlers that index the page by parsing the HTML returned.
I realize the my usage of Vue is quite different than going the route of a SPA and WebPack and the approach often means I can't use 3rd party Vue Components without reworking the code a bit. But the approach simplifies the software architecture and delivers a lightweight reactive UI.
By using this approach Razor can be heavily leveraged to generate the initial rendering of the HTML with some tags containing vue attributes. Then after the page loads in the browser, Vue takes over and can reconfigure that page any way desired.
Obviously, this approach will not fit the needs of all developers or projects but for some use cases it's quite a nice setup.
A few more details for those interested
Since I use vue sitewide, my global _layout.aspx file is responsible for instantiating vue. Any sitewide functionality implemented in vue is implemented at this level. Many pages have page specific vue functionality, this is implemented as a mixin on that page or a mixin in a js file loaded by that page. When the _layout.aspx page instantiates Vue it does so with all the mixins that I have registered to a global mixin array. (The page pushed it's mixin on that global mixin array)
I don’t use .vue files. Any needed components are implemented either directly on the page or if they need to be used by multiple pages then they are implemented in a partial view like the one below.:
dlogViewComponent.cshtml :
#* dlog vue component template*#
<script type="text/x-template" id="dlogTemplate">
<div class="dlog" v-show="dlog.visible" v-on:click="dlog.closeBoxVisible ? close() : ''">
<div class="dlogCell">
<div class="dlogFrame" ##click.stop="" style="max-width:400px">
<i class="icon icon-close-thin-custom dlogCloseIcon" v-if="dlog.closeBoxVisible" ##click="close()"></i>
<div class="dlogCloseIconSpace" v-if="dlog.closeBoxVisible"></div>
<div class="dlogInner">
<div class="dlogTitle" style="float:left" v-text="title"></div>
<div class="clear"></div>
<div class="dlogContent">
<slot></slot>
</div>
</div>
</div>
</div>
</div>
</script>
#* Vue dlog component *#
<script type="text/javascript">
Vue.component('dlog', {
template: '#dlogTemplate',
props: { //don't mutate these!
closeBoxVisible: true,
title: 'One'
},
data: function () {
return {
dlog: { //nest the data props below dlog so I can use same names as cooresponding prop
closeBoxVisible: (typeof this.closeBoxVisible === 'undefined') ? true : (this.closeBoxVisible == 'true'),
title: (typeof this.title === 'undefined') ? '' : this.title,
visible: false
}
}
},
methods: {
//opens the dialog
open: function () {
app.hideBusy(); //just in case, no harm if not busy
this.dlog.visible = true;
var identifyingClass = this.getIdentifyingClass();
Vue.nextTick(function () {
$("." + identifyingClass).addClass("animateIn");
fx.manageDlogOnly();
});
},
//closes the dialog
close: function () {
fx.prepDlogClose();
var identifyingClass = this.getIdentifyingClass();
this.dlog.visible = false;
$("." + identifyingClass).removeClass("animateIn");
},
getIdentifyingClass: function () {
if (this.$el.classList.length > 1) {
//the last class is always our identifying css class.
return this.$el.classList[this.$el.classList.length - 1];
} else {
throw "A dialog must have an identifying class assigned to it.";
}
}
}
});
</script>
In the above, it's the Vue.component('dlog', ... part of the js that installs the component and makes it available to the page.
The vue code on the _layout.cshtml page looks something like the code below. By instantiating Vue on the _layout.cshtml which is used by the whole site, Vue is only instantiated in a single place sitewide:
_layout.cshtml :
<script type="text/javascript">
var app = new Vue({
el: '#appTemplate',
mixins: mixinArray, //The page adds it's mixin to mixinArray before this part of the layout executes.
data: {
errorMsg: '' //used sitewide for error messages
//other data used sitewide
},
methods: {
//methods that need to be available in vue sitewide, examples below:
showBusy: function (html) {
//functionality to show the user that the site is busy with an ajax request.
},
hideBusy: function () {
//functionality to hide the busy spinner and messaging
}
},
created: function () {
//this method is particularly useful for initializing data.
}
});
</script>
What I have provided here paints a pretty clear picture of this non-traditional approach and it's benefits. However, since several people asked, I also wrote a related blog post: Using VueJs with ASP.NET Razor Can Be Great!
You can do this. Sometimes you're obliged to do it, if, like us, you're migrating an existing code base and you can't convert everything at once. And as Ron C says, it works well.
If you're starting a new project, you have the luxury of choosing. Reasons for favouring an SPA and no Razor would be...
Reactivity. SPA apps generally feel (much) more reactive. Initial renders are often served from cache, before the data arrives. On first load, all resources arrive in a bundle, in one request-response. There's no, or much less, request chaining.
Workflow. Webpack, bundling and hot reloads are great. You get production builds, with minification, compilation of Vue render functions, elimination of 404 style errors, js syntax errors are trapped. The cycle from introducing an error to discovering it is greatly reduced for many errors.
SPA universe. Routing, Vuex, this really is the way of the future.
Purity. Razor and Vue do similar things at the end of the day. If you mix them, you may have a hard time keeping your head straight.
You can now also lint the VueJS templates within the Razor views:
https://www.npmjs.com/package/razor-vue-lint
Great answers and content on this question! Just to add re the OP, the official Vue documentation expressly states that you can mix and match and do what you like with Vue and that it is designed to be used incrementally so I'd say if it fits what you're trying to do then it is NOT an automatic bad practice.
Consider the following templates:
layout
pageLayoutStandard
aboutUs
'layout' is my top-level template, which I specify using:
Router.configure({
layoutTemplate: 'layout',
});
Inside layout.html I have the following:
<main id="site-main" role="main">
{{>Template.dynamic template=page.pageLayoutTemplate }}
</main>
I pass some data in from the route: a page object which has a property 'pageLayoutTemplate', having the value 'pageLayoutStandard'.
Inside 'pageLayoutStandard' template, I have:
{{> yield }}
If I visit the '/about-us' route, I render the 'aboutUs' template into 'pageLayoutStandard' - no worries.
And now to my problem...
In my 'aboutUs' template, I expect the 'data' property of the instance to contain the data I passed down from iron-router. However, I find that my the data property contains a 'Template' object; specifically, it contains 'pageLayoutStandard'.
So it looks like 'yield' doesn't like living in a sub-layout - it wants to live at the top level layout for it to get the data from the route. This I validated by moving my yield to the top level layout - the 'aboutUs' template then gets the right data.
Is there any way I can get 'yield' to get the correct data context when it exists in a sublayout?
One solution is to access the data using
Router.current().data()
I my self am fairly new to Iron-Router, but I believe it may be a similar issue that I cam across in another way. There are also several ambiguities in your question, such as where and how are you specifically defining the data context.
Basically I discovered that {{> yield}} creates it's own <body> tags. This also means that things like Template.body.events(); don't propagate into this new Iron-router <body>. This is a known "bug" with Iron-Router.
There is a workaround that has been developed to solve that particular issue, but I'm not sure it's relevant to your case, or at least may not solve the problem since you are not looking to propagate the main body template.
In the end it may be that your routing logic is somewhat inverted, as you mentioned, with the intended usage of Iron-Router.
I believe a better way to perform what you want would be to have:
<main id="site-main" role="main">
{{> yield}}
</main>
With something like this in your router definition
Router.map(function (){
this.route("/about-us", {
template: "pageLayoutStandard"
}
});
You should then be able to set your data context and rendering as per usual.
I've got this in my routes:
Router.route('/videos/:id', {
name: 'VideoPage',
data: function(){
return Videos.findOne(this.params.id);
}
})
This template shows up at the route above:
Template.VideoPage.helpers({
'videoIds': function(){
var myVideoIds = [
"23456",
"h5e45t",
"f4e4w",
"g6h4h"
];
return myVideoIds;
}
});
HTML:
<template name="VideoPage">
{{videoTitle}}
<p>Click the links below to get to a new video page</p>
{{#each videoIds}}
<a href="/videos/" + {{this}}>
{{/each}}
</template>
When I click on a link, the URL in the browser changes from something like /videos/23456 to something like /videos/f4e4w, but the request never actually goes through Iron Router and the Router.route function. I put a debugger before Router.route and it triggers on initial page load but does NOT trigger when the links are clicked.
I understand that Iron Router's default behavior is NOT to re-render a template the user is currently on, but this is the same template with different url params that are used to change the data in the template, so IMO it should still re-render.
Ok, false alarm. It appears that Router.route DOES fire and updates the data context every time the params._id changes. I was placing the debugger outside of the Route function when I should have been placing it inside of the data context function.
The example that I gave in this answer was also a highy, highly simplified example. It wasn't working in my real-life project due to something else (a complex video iframe generator) that was being refreshed improperly.
But rest assured that going from /videos/f4e4w to /videos/23456 by clicking a link DOES still go through Iron Router and the params does get read and the data does get updated.