I have two components, one contains another.
And when I trigger event from child I can't receive it in parent.
Child component
this.$emit('myCustomEvent', this.data);
Parent component
<parent-component v-on:myCustomEvent="doSomething"></parent-component>
But, when I changed event name to my-custom-event in both places it works.
Vue somehow transform event names? Or what can be a problem?
I read docs about component naming convention but there nothing related to event naming
It is recommended to always use kebab-case for the naming of custom events. Lower case events, all smashed together, as recommended by #KoriJohnRoys would also work but are harder to read. It is not recommended to use camelCase for event naming.
The official documentation of Vue.JS states the following under the topic of Event Names:
Event Names
Unlike components and props, event names don’t provide any automatic case transformation. Instead, the name of an emitted event must exactly match the name used to listen to that event. For example, if emitting a camelCased event name:
this.$emit('myEvent')
Listening to the kebab-cased version will have no effect:
<my-component v-on:my-event="doSomething"></my-component>
Unlike components and props, event names will never be used as variable or property names in JavaScript, so there’s no reason to use camelCase or PascalCase. Additionally, v-on event listeners inside DOM templates will be automatically transformed to lowercase (due to HTML’s case-insensitivity), so v-on:myEvent would become v-on:myevent – making myEvent impossible to listen to.
For these reasons, we recommend you always use kebab-case for event names.
In addition to #ssc-hrep3's point on kebab-case
The docs for .sync recommend using the pattern update:myPropName
For custom events, the safest option is to just use a lower-cased event name all smashed together. Currently even kebab-case can have issues.
this.$emit('mycustomevent', this.data);
then, in the parent component, feel free to bind to a camel-cased function
<parent-component v-on:mycustomevent="doSomething"></parent-component>
it's a bit janky, but it works.
Source (states that kebab-case doesn't work either)
Vue.js transforms not only xml tags (component names) but attributes as well, so when you are generating event
$emit('iLikeThis')
you must handle it as:
v-on:i-like-this="doSomething"
From docs:
When registering components (or props), you can use kebab-case,
camelCase, or TitleCase.
...
Within HTML templates though, you have to use the kebab-case
equivalents:
Related
In re-frame, components will be automatically updated when a subscription they deref has an update. This is generally used for all kinds of dom elements under a single element (in general a div) somewhere under html>body.
I would like to do the same for style that lives under html>head, i.e. the style should be updated in response to subscription updates.
The spade library allows one to define
"global" style, which is easy to setup once and for all
inline style, which is generated in the react/reagent component's render function and as such can be updated based on subscriptions *)
Now I would like to define style that is not inline, yet is reactive to subscriptions. How can this be done?
My best idea currently is to try to call (reagent.dom/render [my-style] head-el) a second time (in addition to the main rendering done to that div under html>body). Not sure if that is possible or idiomatic.
*) Although only (defattrs) is strictly speaking "inline style" (i.e. something like <elem style=...>), the other option (defclass) (being rendered as <elem class=...> with a corresponding style definition under html>head) is similar in that the style is always updated together with the element, i.e. I cannot seem to update the style of the class separately from rendering the element, e.g. one subscription leads to element changes, whereas another subscription leads to style changes (only).
Im actually learning Vue3.
It seems generally very clear to me.
But one thing is not clear at all.
The differecens between watch and beforeUpdate.
There are differences between this two?
And if yes, when is preferred use one rather than another?
Yes there are many differences. Watch observes only changes in the reactive data passed as the first argument, so it only operates after the monitored properties have changed. As for beforeUpdate , it is a life cycle that is called before the DOM is changed due to reactive data changes in the component, So it observes any reactive data in the component.
i think watch will triggerd after changing the data but beforeUpgrade is a hook and will look at the DOM for runnig something
With beforeUpdate you can listen to any change in the component. It will be called if any of the reactive elements change that is used in rendering the component.
With watch you can listen to specific reactive elements, even if they are not used in rendering the component.
Vue 3 introduced the option to declare a components emitted events in the emits option, while also removing the $listeners attribute in favor of the $attrs.
In $attrs event listeners for events get added an prefixed with on so an event called click is accessed in the component through $attrs.onClick. But when the click events is declared in the emits option, it dissapears from $attrs.
This is made by design in Vue 3, since the $attrs attribute only is meant to include things not declared in the component.
If you want to access the components event listeners, while having them declared, you can change them to props and propagate the listening function into the component that was like mentioned here.
There's also a discussion on the Vue.js core Github about this behaviour here.
Is there any systematic structure for Vue component? In which order computed , methods, components, mounted watch etc should be written?
Update
For component I mostly prefer putting script tags before html tags. As the idea that we mostly use to play with js so I feel itchy to move down always in the page. Else make your layout as per your preference
As per Vue official style guide -
Component/instance options should be ordered consistently.
This is the default order we recommend for component options. They’re split into categories, so you’ll know where to add new properties from plugins.
Side Effects (triggers effects outside the component)
el
Global Awareness (requires knowledge beyond the component)
name
parent
Component Type (changes the type of the component)
functional
Template Modifiers (changes the way templates are compiled)
delimiters
comments
Template Dependencies (assets used in the template)
components
directives
filters
Composition (merges properties into the options)
extends
mixins
Interface (the interface to the component)
inheritAttrs
model
props/propsData
Local State (local reactive properties)
data
computed
Events (callbacks triggered by reactive events)
watch
Lifecycle Events (in the order they are called)
beforeCreate
created
beforeMount
mounted
beforeUpdate
updated
activated
deactivated
beforeDestroy
destroyed
Non-Reactive Properties (instance properties independent of the reactivity system)
methods
Rendering (the declarative description of the component output)
template/render
renderError
For more recommended style-guide of Vue - Look here vue-style-guide
No, there is not. 100% personal preference. I like to start with the data, methods and usually end with the lifecycle methods. That is similar to how it is usually positioned in the docs and seems convenient because data and methods get changed a lot, and lifecycle methods not so much. However, there is no reason to do it like that from the framework. Go your game.
It's possible to maintain the order of object keys in practice in JavaScript, but this isn't guaranteed for ES5 specification, which is supported by Vue. So it shouldn't be expected that the framework will rely on the order in which component properties are defined.
Component functions can maintain a certain order for consistency like other answers explains, but they should not. This is purely a matter of style.
mount on a component does not fire for v-bind changes to the component in the root.
I have a dynamic component where I often change the value of the data referenced in v-bind:is and v-bind attributes, switching the current component and its data. This works great to show different "screens" of my application.
I have some logic that happens on mount for many of the components. However, this only gets called when the v-bind:is value is changed, but no when only the v-bind attribute is. That sort of makes sense to me, though I do need to capture either.
I'm new to Vue and there is a lot of documentation. I'm so far unable to determine if there's a built-in functionality for a callback to v-bind:is and v-bind. Can anyone help me out here?