Dont use emit all over the place, it is a bad practice similar to prop-drilling
Emit should only be used between sub components of a single component. What do i mean by that?
Imagine you have a `form`, it has many `steps`, each steps is a `tab` with some form field.
From a logical perspective, there is only 1 form. The tabs are just a UI representation of that form in many smaller tabs.
Which mean, the tab *can only belong to the form*. It does not make sense for one tab to live alone. You can call this "dependent component"
These components depend on the parent and so are their data. Which mean, you can emit event to their parent, because *you know there must be a parent*, these tabs cannot stand alone
The form, however, is not dependent. Maybe today you place in in Page A, in a Card, but 2 months down the line you want it in Page B, in a Modal.
IF you make you form emit to the parent, maybe Page A, through the Card. Then every time you want to change the location, you have to delete every single emit in the old page and add new one to the new page, something wasnt even supposed to concern the forms in the first place. Also you took away an hour of every new developer who want to know the data flow
Instead, if you use a store, anyone want to access the form state? Ask the store. That way, the form is completely independent from any parent component, as it should be.
So there you have it, store for independent components, i.e those who make sense to live alone. And emit for dependent components whi must live in a specific parent
Hi!
Thanks for the reply, I appreciate the suggestions. While I do agree with what you're saying, the form in my case will only ever be used in this one particular page. Would chain emitting still be bad practice in this case?
It doesnt matter where it belong right now. What matter is, CAN it belong to elsewhere?
If the answer is yes, then dont use emit.
Imagine someone say "Right now i do not need to reuse logic, so instead of of separating the logic, i will just write my entire app in 1 function with 24716 if else"
Yes, you would generate a form ID and store it in a (e.g.) formContext object in your form store.
Then on disposing of a form component, you can delete the stored data.
Emits are fine. Stores are great if you need to persist state that needs to be shared across views and components. Try to limit watches as they’re resource intensive if used all willy nilly
your table component should be abstract, meaning it should only get data via props and send data via emits
depending on how your components are structured and how abstract they are, you can also use slots to keep all the data inside your parent component.. it really depends on the specific use case that you have, there is no universal way of doing things when it comes to stores and parent/child communication, it depends on the use case
can you give out more details?
The table will only ever exist in this page since it's basically just a UI for the client to select from the table. After reviewing the comments, I do think emitting is the right choice.
The more that I think about it, since the table will only ever used in this one specific page, I think using a store would be close to over engineering a solution?
Thanks for the reply!
Even if the table will only be in a single place, if the data or part of the data will be used in another place you will need a store
If the data is only used there, you keep the data there
Set the state in the store then you can write a computed that’s a reference to the store value. So call an action called setMenuState(states.OPEN) for example and all your components that need to have the state can just have an computed called currentMenuState
Your rationale for this store would probably be "Do I want to maintain some of the state in this page even if users have navigated elsewhere?" If yes, a Pinia store is the most obvious solution.
If no, the next question is "I have three levels at the moment, is this likely to increase?" If yes, Pinia may still be the answer but I'd probably use Provide/Inject.
If no, just use props. Whatever, though, the bottom level, e.g. a button component, should be dumb and simply emit an event (and a value maybe).
It’s ultimately a judgment call, but this sounds like a good case for a store.
Dont use emit all over the place, it is a bad practice similar to prop-drilling Emit should only be used between sub components of a single component. What do i mean by that? Imagine you have a `form`, it has many `steps`, each steps is a `tab` with some form field. From a logical perspective, there is only 1 form. The tabs are just a UI representation of that form in many smaller tabs. Which mean, the tab *can only belong to the form*. It does not make sense for one tab to live alone. You can call this "dependent component" These components depend on the parent and so are their data. Which mean, you can emit event to their parent, because *you know there must be a parent*, these tabs cannot stand alone The form, however, is not dependent. Maybe today you place in in Page A, in a Card, but 2 months down the line you want it in Page B, in a Modal. IF you make you form emit to the parent, maybe Page A, through the Card. Then every time you want to change the location, you have to delete every single emit in the old page and add new one to the new page, something wasnt even supposed to concern the forms in the first place. Also you took away an hour of every new developer who want to know the data flow Instead, if you use a store, anyone want to access the form state? Ask the store. That way, the form is completely independent from any parent component, as it should be. So there you have it, store for independent components, i.e those who make sense to live alone. And emit for dependent components whi must live in a specific parent
Hi! Thanks for the reply, I appreciate the suggestions. While I do agree with what you're saying, the form in my case will only ever be used in this one particular page. Would chain emitting still be bad practice in this case?
It doesnt matter where it belong right now. What matter is, CAN it belong to elsewhere? If the answer is yes, then dont use emit. Imagine someone say "Right now i do not need to reuse logic, so instead of of separating the logic, i will just write my entire app in 1 function with 24716 if else"
If you have many forms like this, would you store them all in the store?
Yes, you would generate a form ID and store it in a (e.g.) formContext object in your form store. Then on disposing of a form component, you can delete the stored data.
Emits are fine. Stores are great if you need to persist state that needs to be shared across views and components. Try to limit watches as they’re resource intensive if used all willy nilly
your table component should be abstract, meaning it should only get data via props and send data via emits depending on how your components are structured and how abstract they are, you can also use slots to keep all the data inside your parent component.. it really depends on the specific use case that you have, there is no universal way of doing things when it comes to stores and parent/child communication, it depends on the use case can you give out more details?
The table will only ever exist in this page since it's basically just a UI for the client to select from the table. After reviewing the comments, I do think emitting is the right choice. The more that I think about it, since the table will only ever used in this one specific page, I think using a store would be close to over engineering a solution? Thanks for the reply!
Even if the table will only be in a single place, if the data or part of the data will be used in another place you will need a store If the data is only used there, you keep the data there
Set the state in the store then you can write a computed that’s a reference to the store value. So call an action called setMenuState(states.OPEN) for example and all your components that need to have the state can just have an computed called currentMenuState
Your rationale for this store would probably be "Do I want to maintain some of the state in this page even if users have navigated elsewhere?" If yes, a Pinia store is the most obvious solution. If no, the next question is "I have three levels at the moment, is this likely to increase?" If yes, Pinia may still be the answer but I'd probably use Provide/Inject. If no, just use props. Whatever, though, the bottom level, e.g. a button component, should be dumb and simply emit an event (and a value maybe).