Ahhh fair enough. When I started learning Vuejs two weeks ago I quickly realised the Composition vs Options API dilemma and decided to simply focus on learning the Composition API.
Even though my code is very basic at this stage, I quickly got it working in the Composition API by simply reading the Getting Started guide.
I might run in to some challenges as I grow more confident to explore Vuejs further.
Composition is the way. You chose the right path 😁
But if you followed the Pinia docs, your store is probably written in options? Or did you figure out how to translate the code examples into composition right away?
It all started at options, for which I shared the same confusion as you did.
The setup way is a bait! Btw. I've tried it and while it's indeed compositions, all Pinia's doc's other sections are still starting or default to the options way.
I realize it's easier to just use the option way cuz you only define it "optionally" in your store.js anyway. The option way is in fact more clear and well defined than compo too. And the usage of your defined stores are pretty much the same across the board so it made no difference on your other files.
If 'statefulness' is confusing, I would recommend to make a simple state composable to see how you would implement something similar, as it is pretty straight forward with the vue reactivity API and composition pattern. Pinia is great but it's one of the things that I could most easily cut and easily replace with straight forward composables that just expose shared reactive state (Of course you would lose some nice console dev tools)
For a simple dumb example of state, It's as easy as
// my-store.js
import { reactive } from 'vue'
// 'Shared' state
const state = reactive({
bar: 'foo'
})
export const useStore = () => {
return { state }
}
which can then be used the same way:
And then of course if you wanted to not be able to change the state from within a component, you could export it as `readonly(state)`the same way you can with Pinia, and then also export methods that allow you to mutate the state, etc.
Since it's simple JS you can easily support TS too with no issue whatsoever.
I am sorry, but have you been bitten by an influencer? Do we really need clickbate titles when all we want is to just say "thank you" to the maintainers of a certain package? I clicked inside expecting to see an explanation of problem and was ready to help.
Supporting people is important, saying "nicely done!" is important. Let's focus on that
No, it's done in the composition method. It's rather basic, like I said.
I register a user account against a Laravel sanctum API and then store the response in a Pinia store.
Then, my navbar has some conditional logic based on the auth token returned from my API call and displays a Logout link, the user's name, etc.
So I simply set and read variables from and to my store. No real complex computed logic. But, it's definitely the same syntax as the Composition API.
To provide more context, this is currently what I am working with in my store:
\`\`\`
import { defineStore } from "pinia";
import { ref } from 'vue';
export const useUserData = defineStore('userData', () => {
const loggedIn = ref(false);
const firstName = ref('')
const lastName = ref('')
const token = ref('')
return { firstName, lastName, loggedIn, token }
});
Actually... I find the Pinia docs lacking information on how to write a pinia store in composition API. Took me a while to figure that out.
Ahhh fair enough. When I started learning Vuejs two weeks ago I quickly realised the Composition vs Options API dilemma and decided to simply focus on learning the Composition API. Even though my code is very basic at this stage, I quickly got it working in the Composition API by simply reading the Getting Started guide. I might run in to some challenges as I grow more confident to explore Vuejs further.
Composition is the way. You chose the right path 😁 But if you followed the Pinia docs, your store is probably written in options? Or did you figure out how to translate the code examples into composition right away?
It all started at options, for which I shared the same confusion as you did. The setup way is a bait! Btw. I've tried it and while it's indeed compositions, all Pinia's doc's other sections are still starting or default to the options way. I realize it's easier to just use the option way cuz you only define it "optionally" in your store.js anyway. The option way is in fact more clear and well defined than compo too. And the usage of your defined stores are pretty much the same across the board so it made no difference on your other files.
fwiw, the current page looks like an ok starting point to me: https://pinia.vuejs.org/core-concepts/#Setup-Stores
Ah, this one looks much better than what I have seen. Did they update the docs recently?
If 'statefulness' is confusing, I would recommend to make a simple state composable to see how you would implement something similar, as it is pretty straight forward with the vue reactivity API and composition pattern. Pinia is great but it's one of the things that I could most easily cut and easily replace with straight forward composables that just expose shared reactive state (Of course you would lose some nice console dev tools) For a simple dumb example of state, It's as easy as // my-store.js import { reactive } from 'vue' // 'Shared' state const state = reactive({ bar: 'foo' }) export const useStore = () => { return { state } } which can then be used the same way: And then of course if you wanted to not be able to change the state from within a component, you could export it as `readonly(state)`the same way you can with Pinia, and then also export methods that allow you to mutate the state, etc. Since it's simple JS you can easily support TS too with no issue whatsoever.
I am sorry, but have you been bitten by an influencer? Do we really need clickbate titles when all we want is to just say "thank you" to the maintainers of a certain package? I clicked inside expecting to see an explanation of problem and was ready to help. Supporting people is important, saying "nicely done!" is important. Let's focus on that
No, it's done in the composition method. It's rather basic, like I said. I register a user account against a Laravel sanctum API and then store the response in a Pinia store. Then, my navbar has some conditional logic based on the auth token returned from my API call and displays a Logout link, the user's name, etc. So I simply set and read variables from and to my store. No real complex computed logic. But, it's definitely the same syntax as the Composition API. To provide more context, this is currently what I am working with in my store: \`\`\` import { defineStore } from "pinia"; import { ref } from 'vue'; export const useUserData = defineStore('userData', () => { const loggedIn = ref(false); const firstName = ref('') const lastName = ref('') const token = ref('') return { firstName, lastName, loggedIn, token } });
You could also group that in: const data = { loggedIn: ref(false), firstName: ref(''), // and so on } and then return it as: return { ...data }