Why is this composable not reactive? - vue.js

I have this composable in my app:
// src/composition-api/usePermissions.js
import { ref, readonly } from 'vue'
import { fetchData } from 'src/utils/functions/APIFunctions'
export function usePermissions() {
const permissions = ref([])
const name = ref('')
const fetchCurrentUser = () => {
fetchData('users/me').then(res => {
name.value = `${res.first_name} ${res.last_name}`
permissions.value = res.roles
})
}
return {
name: readonly(name),
permissions: readonly(permissions),
fetchCurrentUser,
}
}
FetchCurrentUser is called in the main layout component.
<template>
<!-- src/layouts/MainLayout.vue -->
<q-layout view="lHh Lpr lFf">
<!-- Redacted for brevity -->
</q-layout>
</template>
<script setup>
import { defineComponent, ref, onMounted } from "vue";
import EssentialLink from "src/components/EssentialLink.vue";
import { usePermissions } from "src/composition-api/usePermissions";
const { fetchCurrentUser } = usePermissions();
/* redacted for brevity */
onMounted(() => {
fetchCurrentUser();
});
</script>
And the state is used in other components, such as this one.
<template>
<!-- src/components/loggedUserLabel.vue -->
<div>{{ name }}</div>
</template>
<script setup>
import { usePermissions } from "src/composition-api/usePermissions.js";
const { name } = usePermissions();
</script>
The fetchCurrentUser() function is used when starting the app or when a new user logs in. I want to use this composable in other components to restrict access to some parts of the app depending on user permissions, and to display the username. However, the name and permissions properties are not reacting to changes. What could be wrong here?
If it matters, I'm using Quasar. I could use Pinia for this but I only need this kind of store-like shared state here, so it seems like overkill to add another library.
At Estus Flask's request, I have created a MCVE - and the same problem keeps happening. Note how in src/layouts/MainLayout.vue the API call is made, but the message in src/components/PokemonLabel.vue does not update, despite receiving a valid response from the Pokeapi.
I have found a similar answered question but it is about a different situation.
Thanks in advance for your help!

name and fetchCurrentUser are supposed to be used in the same component. The state of fetchCurrentUser isn't shared between components, this is by design.
In order to make the state global, it should be created once per component hierarchy, e.g.:
const name = ref('')
export function usePermissions() {
const fetchCurrentUser = ...
return {
name: readonly(name),
fetchCurrentUser,
}
}
This won't work correctly for SSR application like Quasar because there are multiple application instances for different users, but the state is created once and shared between them. In this case the state likely should be created for a hierarchy of components, e.g.:
export function setupPermissions() {
const name = ref('')
const fetchCurrentUser = ...
provide('permissionsStore', {
name: readonly(name),
fetchCurrentUser,
})
}
export function usePermissions() {
return inject('permissionsStore');
}
Where usePermissions is used in child component. And setupPermissions is used in root component, or can be rewritten as a plugin.

Related

Is there a 'simple' way to dynamically render views in vue?

Let's take a step back and look at the use case:
You're defining a modular interface, and any module that implements it must be able to 'render itself' into the application given a slot and a state.
How do you do it in vue?
Example solution
Let's have a look at the most basic implementation I can assemble:
(full example:
https://stackblitz.com/edit/vitejs-vite-8zclnp?file=src/App.vue)
We have a layout:
# Layout.vue
<template>
<div>
<hr />
<slot name="moduleView" />
<hr />
</div>
</template>
...and an app with a module:
# App.vue
<script lang="ts" setup>
import type { MyModuleState } from "./MyModule";
import Layout from "./Layout.vue";
import { ref } from "vue";
import { MyModule } from "./MyModule";
import ModView from "./ModView.vue";
const state = ref<MyModuleState>({ value: 0 });
const module = new MyModule();
const onClick = () => {
state.value = { value: state.value.value + 1 };
};
const renderModule = () => {
return module.view(state.value);
};
</script>
<template>
<div>currentValue: {{ state.value }}</div>
<div>update: <button #click="onClick">++</button></div>
<div>
<Layout>
<template v-slot:moduleView>
<mod-view :render="renderModule" :state="state" /> // <--- But this!
</template>
</Layout>
</div>
</template>
...but rendering into the slot requires a lot of jumping through obscure hoops:
# ModView.vue
<script lang="ts" setup>
import ModRender from "./ModRender";
import { ref, watch } from "vue";
import type { VNode } from "vue";
const props = defineProps<{
render: (state?: any) => VNode | Array<VNode>;
state?: any;
}>();
const nodes = ref(props.render(props.state));
watch( // <-- Obscure! The view won't update unless you explicitly watch props?
() => props.state,
(nextState) => {
nodes.value = props.render(nextState);
}
);
</script>
<template>
<mod-render :nodes="nodes" />
</template>
# ModRender.ts
import type { VNode } from "vue";
const ModRender = (props: { nodes: VNode | Array<VNode> }) => {
return props.nodes;
};
ModRender.props = {
nodes: {
required: true,
},
};
export default ModRender; // <--- Super obscure, why do you need a functional component for this?
Before we can define the actual module:
# MyModule.ts
import type { VNode } from "vue";
import { h } from "vue";
import ModuleView from "./MyModuleDisplay.vue";
interface AbstractModule<T> {
view: (state: T) => VNode;
}
export interface MyModuleState {
value: number;
}
export class MyModule implements AbstractModule<MyModuleState> {
view(state: MyModuleState): VNode {
return h(ModuleView, { state });
}
}
...and a component for it:
# MyModuleView.vue
<script setup lang="ts">
import type { MyModuleState } from "./MyModule";
const props = defineProps<{ state: MyModuleState }>();
</script>
<template>
<div>{{ state.value }}</div>
</template>
What.
This seems extremely obtuse and verbose.
Am I missing something?
In other component systems an implementation might look like:
export class MyModule implements AbstractModule<MyModuleState> {
view(state: MyModuleState): VNode {
return (<div>{state.value}</div>);
}
}
...
<div>
<Layout>{renderModule(state)}</Layout>
</div>
It seems surprising that so many wrappers and hoops have to be done in vue to do this, which makes me feel like I'm missing something.
Is there an easier way of doing this?
Vnode objects cannot be rendered in component templates as is and need to be wrapped in a component like ModRender. If they are used as universal way to exchange template data in the app, that's a problem. Vnodes still can be directly used in component render functions and functional components with JSX or h like <Layout>{renderModule(state)}</Layout>, this limits their usage.
AbstractModule convention may need to be reconsidered if it results in unnecessary code. Proceed from the fact that a "view" needs to be used with dynamic <component> at some point, and it will be as straightforward as possible.
There may be no necessity for "module" abstraction, but even if there is, module.view can return a component (functional or stateful) instead of vnodes. Or it can construct a component and make it available as a property, e.g.:
class MyModule {
constructor(state) {
this.viewComponent = (props) => h(ModuleView, { state, ...props })
}
}

Why does calling "useUserStore(store)" in a Quasar boot file breaks the Pinia Persistedstate Plugin?

I'm trying to use the Pinia Persisted State Plugin with Pinia in my Quasar app (Vue 3 / TypeScript).
Out of the box everything works fine.
But when using a Quasar boot file the persisted state stops working. Refreshing the page wipes all the new values away.
I don't know why the boot file breaks the persisted state plugin, but I have narrowed the culprit down to a single line...
This is how I am using Pinia with Quasar and adding the plugin:
src/store/index.ts
/* eslint-disable #typescript-eslint/no-unused-vars */
import { store } from 'quasar/wrappers';
import { createPinia, Pinia } from 'pinia';
import piniaPluginPersistedstate from 'pinia-plugin-persistedstate';
declare module '#quasar/app' {
interface BootFileParams<TState> {
store: Pinia;
}
interface PreFetchOptions<TState> {
store: Pinia;
}
}
declare module '#vue/runtime-core' {
interface ComponentCustomProperties {
$store: import('pinia').Pinia;
}
}
export default store(function (_) {
const pinia = createPinia();
pinia.use(piniaPluginPersistedstate); // Pinia Plugin added here
return pinia;
});
And this is what my Pinia store looks like:
src/store/user.ts
import { defineStore } from 'pinia';
export const useUserStore = defineStore('user', {
state: () => {
return {
user: {
firstName: 'Mary',
},
};
},
persist: true, // Note that we are using a persisted state here
actions: {
setFirstName(firstName: string) {
this.user.firstName = firstName;
console.log('Name set to Pinia store: ', this.user.firstName);
},
getFirstName() {
if (!this.user.firstName) {
console.log('No name found in store. Setting "John" to Pinia store.');
this.user.firstName = 'John';
return this.user.firstName;
} else {
console.log('Name fetched from Pinia store: ', this.user.firstName);
return this.user.firstName;
}
},
},
});
Here is an example front-end page for fetching and setting the firstName:
src/pages/index.vue
<template>
<div>{{ firstName }}</div>
<q-form #submit="handleFirstNameSubmit">
<p>Change First Name</p>
<q-input v-model="firstNameInput" filled outline />
<q-btn label="Submit Name to Pinia Store" type="submit" />
</q-form>
<q-btn #click="handleFirstNameFetch" label="Fetch Name from Pinia Store" />
</template>
<script setup lang="ts">
import { ref } from 'vue';
import { useUserStore } from 'src/store/user';
const userStore = useUserStore();
const firstName = ref<string>();
const firstNameInput = ref<string>();
const handleFirstNameSubmit = () => {
if (firstNameInput.value) {
userStore.setFirstName(firstNameInput.value);
}
};
const handleFirstNameFetch = () => {
firstName.value = userStore.getFirstName();
};
</script>
Up to this point everything works fine.
I can set firstName to the Pinia store, refresh the page, and the new name is still in Pinia.
But when using const userStore = useUserStore(store) inside a boot file like the example below, the persisted state stops working:
src/boot/auth.ts
import { boot } from 'quasar/wrappers';
import { useUserStore } from 'src/store/user';
export default boot(({ store }) => {
const userStore = useUserStore(store);
// Do some other authentication stuff, setting initial user store values etc, below here...
});
Any idea what's going on? And how to fix it?
I think this plugin is much cleaner than using the alternate LocalStorage persisted state solution so I would love to get it working with Quasar.
everyone after a lot of research I found the answer to this issue,
you must pass index.ts/js for const like below:
this is worked for me in quasar.:)
<script lang="ts" setup>
import store from '../stores/index';
import { useCounterStore } from '../stores/counter';
const counterStore = useCounterStore(store());
counterStore.increment();
console.log(counterStore.count);
</script>
A common use case for Quasar applications is to run code before the root Vue app instance is instantiated.
If the app is not instantiated then the pinia plugin hasn't been installed yet. See: https://github.com/vuejs/pinia/discussions/723#discussioncomment-2110660

How Do I Share Async API Data across Components in Vue 3?

I have a top-level component that gets data from an API at regular intervals. I want to make a single API request and get all the data for my app in one place to reduce the number of requests to the API server. (FYI, my project looks like it's using Typescript but I'm not yet.)
Everything works fine in my top-level component:
//Parent
<script lang="ts">
import { defineComponent, ref, provide, inject, onMounted } from 'vue'
import getData from '#/data.ts'
export default defineComponent({
setup(){
const workspaces = ref([])
onMounted(async () => {
let api = inject('api') //global var from main.ts
let data = await getData(api) //API request inside data.ts
console.log(data.workspaces) //<-- data looks good here
workspaces.value = data.workspaces
//Trying to share workspaces with other components
provide('workspaces', data.workspaces)
})
return {
workspaces
}
}
})
</script>
<template>
{{ workspaces}} <!-- workspaces render fine here -->
</template>
But my child can't use the provide data via inject:
//Child
<script lang="ts">
import { defineComponent, inject, onMounted, ref } from 'vue'
export default defineComponent({
setup(){
let workspaces = ref([])
onMounted(async () => {
workspaces.value = await inject('workspaces') //<-- just a guess; doesn't work
})
return{
workspaces
}
}
})
</script>
<template>
{{ workspaces }} <!-- nothing here -->
</template>
I've made a couple assumptions as to the cause of the problem:
The Child component loads before the parent's async stuff is done, and is therefore empty.
I probably can't use project/inject in async scenarios like this.
So how can I share async data from an API across components in my app? Is my only option to go back to old-school props and pass the data down manually?
provide/inject are misused and subject to race conditions. Composition API is generally supposed to be at used on component initialization (setup, before any await) and not in onMounted. Even if there weren't such restriction, onMounted in parent component runs after the one in child component and can't provide a value at the time when a child is mounted.
The purpose of refs is to provide a reference to a value that can be changed later, so it could be passed by reference and stay reactive, this property isn't currently used.
It should be in parent component:
setup(){
const workspaces = ref([])
provide('workspaces', workspaces)
let api = inject('api')
onMounted(async () => {
let data = await getData(api)
workspaces.value = data.workspaces
})
return { workspaces }
In child component:
setup(){
let workspaces = inject('workspaces')
return { workspaces }

this.$forceUpdate equivalent in Vue 3 - Composition API?

In Vue 2, instance method this.$forceUpdate() could be used to update the component manually. How can we force update component in Vue 3 - Composition API (inside setup method) ?
setup(props, context) {
const doSomething = () => {
/* how to call $forceUpdate here? */
}
return {
doSomething
}
}
Thanks, in advance.
If using Options API:
<script lang="ts">
import {getCurrentInstance, defineComponent} from 'vue'
export default defineComponent({
setup() {
const instance = getCurrentInstance();
instance?.proxy?.$forceUpdate();
}
})
</script>
If using Composition API with <script setup>
<script setup lang="ts">
import { getCurrentInstance } from 'vue'
const instance = getCurrentInstance();
instance?.proxy?.$forceUpdate();
</script>
When I need to force an update in vue I usually add a key with a value I can change, which will then force vue to update it. That should work in vue 3 as well, though I admit I haven't ever tried it. Here's an example:
<template>
<ComponentToUpdate
:key="updateKey"
/>
</template>
<script>
export default {
data() {
return {
updateKey: 0,
};
},
methods: {
forceUpdate() {
this.updateKey += 1;
}
}
}
</script>
You can read more about it here: https://michaelnthiessen.com/key-changing-technique/
$forceUpdate is still available in Vue3, but you won't have access to it in the setup() function. If you absolutely need to use it, you can use object API component or this fancy trick...
app.component("my-component", {
template: `...`,
methods: {
forceUpdate(){
this.$forceUpdate()
}
},
setup(props) {
const instance = Vue.getCurrentInstance();
Vue.onBeforeMount(()=>{
// instance.ctx is not populated immediately
instance.ctx.forceUpdate();
})
return {doSomething};
},
})
If this seems like a ridiculous solution, trust your Judgement. Ideally your application would not rely on forceUpdate. If you are relying on it, it likely means that something is miss-configured, and that should be the first thing to resolve.

Vue 3 Composition API reuse in multiple components

I have these files
App.vue, Header.vue, search.js and Search.vue
App.vue is normal and just adding different views
Header.vue has an input box
<input type="text" v-model="searchPin" #keyup="searchResults" />
<div>{{searchPin}}</div>
and script:
import useSearch from "#/compositions/search";
export default {
name: "Header",
setup() {
const { searchPin, searchResults } = useSearch();
return {
searchPin,
searchResults
};
}
};
search.js has the reusable code
import { ref } from "vue";
export default function useSearch() {
const searchPin = ref("");
function searchResults() {
return searchPin.value;
}
return {
searchPin,
searchResults
};
}
Now, this is working well.. once you add something on the input box, it is showing in the div below.
The thing I have not understood is how to use this code to a third component like Search.vue.
I have this, but its not working.
<template>
<div>
<h1 class="mt-3">Search</h1>
<div>{{ searchPin }}</div>
</div>
</template>
<script>
import useSearch from "#/compositions/search";
export default {
name: "Search",
setup() {
const { searchPin, searchResults } = useSearch();
return {
searchPin,
searchResults
};
}
};
</script>
What am I missing? Thanks.
The fix for this is very simple
instead of
import { ref } from "vue";
export default function useSearch() {
const searchPin = ref("");
function searchResults() {
return searchPin.value;
}
return {
searchPin,
searchResults
};
}
use
import { ref } from "vue";
const searchPin = ref("");
export default function useSearch() {
function searchResults() {
return searchPin.value;
}
return {
searchPin,
searchResults
};
}
The problem is that the searchPin is scoped to the function, so every time you call the function, it gets a new ref. This is a desirable effect in some cases, but in your case, you'll need to take it out.
Here is an example that uses both, hope it clears it up.
const {
defineComponent,
createApp,
ref
} = Vue
const searchPin = ref("");
function useSearch() {
const searchPinLoc = ref("");
function searchResults() {
return searchPin.value + "|" + searchPinLoc.value;
}
return {
searchPin,
searchPinLoc,
searchResults
};
}
const HeaderComponent = defineComponent({
template: document.getElementById("Header").innerHTML,
setup() {
return useSearch();
},
})
const SearchComponent = defineComponent({
template: document.getElementById("Search").innerHTML,
setup() {
return useSearch();
}
})
createApp({
el: '#app',
components: {
HeaderComponent, SearchComponent
},
setup() {}
}).mount('#app')
<script src="https://unpkg.com/vue#3.0.0-rc.9/dist/vue.global.js"></script>
<div id="app">
<header-component></header-component>
<search-component></search-component>
</div>
<template id="Header">
searchPin : <input type="text" v-model="searchPin" #keyup="searchResults" />
searchPinLoc : <input type="text" v-model="searchPinLoc" #keyup="searchResults" />
<div>both: {{searchResults()}}</div>
</template>
<template id="Search">
<div>
<h1 class="mt-3">Search</h1>
<div>both: {{searchResults()}}</div>
</div>
</template>
Adding flavor to #Daniel 's answer.
This is exactly what I'm struggling with regarding to best practices ATM and came to some conclusions:
Pulling the Ref outside of the composition fn would fix your problem but if you think about it, it's like sharing a single instance of a data property used in multiple places. You should be very careful with this, since ref is mutable for whoever pulls it, and will easily break unidirectional data flow.
For e.g. sharing a single Ref instance between a parent component and a child components can be compared to passing it down from parent's data to child's props, and as I assume we all know we should avoid mutating props directly
So classical answer for your question would be, move it to Vuex state and read it from there.
But if you have a small application, don't want a state manager, or simply want to take full advantage of the composition API, then my suggestion would be to at least do something of this pattern
import { ref, computed } from "vue";
const _searchPin = ref(""); // Mutable persistant prop
const searchPin = computed(() => _searchPin.value); // Readonly computed prop to expose
export default function useSearch() {
function searchResults() {
return searchPin.value;
}
return {
searchPin,
searchResults
};
}
Not more than ONE component should mutate the persistent Ref while others could only listen to the computed one.
If you find that more than one component needs access to change the ref, then that's probably a sign you should find another way to implement this (Vuex, props and events, etc...)
As I said, I am still trying to make sense of this myself and am not sure this is a good enough pattern either, but it's definitely better then simply exposing the instance.
Another option for code arrangement would be to encapsulate in 2 different access hooks
import { ref, readonly } from "vue";
const searchPin = ref(""); // Mutable persistant prop
export const useSearchSharedLogic() {
return readonly({
searchPin
})
}
const useSearchWriteLogic() {
return {
searchPin
}
}
// ----------- In another file -----------
export default function useSearch() {
const { searchPin } = useSearchSharedLogic()
function searchResults() {
return searchPin.value;
}
return {
searchPin,
searchResults
};
}
Or something of this sort (Not even sure this would work correctly as written).
Point is, don't expose a single instance directly
Another point worth mentioning is that this answer takes measure to preserve unidirectional data flow pattern. Although this is a basic proven pattern for years, it's not carved in stone. As composition patterns get clearer in the close time, IMO we might see people trying to challenge this concept and returning in some sense to bidirectional pattern like in Angular 1, which at the time caused many problems and wasn't implemented well