VueJS convention and scope - vue.js

I looked in the documentation, on the forum ... I would like to know this:
When I create a component with a scoped style. Should I use classes or id for my DOM ? I prefer ID because this element is unique.
ex:
<template>
<div id="wrapper"> // or class="wrapper" ?
<button id="myBtn">CLICK</button> // or class="myBtn" ?
<div v-for="i in 5" :key="i" class="myDiv">{{i}}</div> // sure class in this case :D
</div>
</template>
For the methods of the component must prefix by $ _mycomposant_methods or can I directly write method?
Same for computed?
I imagine that when compiling (webpack) each component is scoped but I would like to be sure to avoid edge effects.
Thank you

You do not need either.
Vue will automatically take care of the scope and give the component a unique data-hash which then is taken to write your css. It really works well. Give it a try ;)
And your methods and computed properties are working just like normal. nothing to take care of.

For the first question, I think you should keep using class.
Although with the help of component-scoped CSS, you don't need to worry much about the interference from other components' stylesheets, all the templates will still be merged into one document. Vue.js just adds unique data attributes to the elements, it doesn't guarantee every id's uniqueness you defined.
So in order to keep flexibility and avoid potential troubles, it will be a wise choice to follow specifications of HTML which means keeping wrapper as a class if it appears in your HTML document several times.
For the second and third question, I prefer to keep the method names easy to read and understandable. All the JavaScript code will going to be minified and uglified, so there's no need to add any prefix.

Related

How to prevent hydration of Nuxt when using SSR?

We are using this approach to rendering content:
<div id="full-article" v-html="content"></div>
this.content = api.response.data
In this approach, "content" is retrieved from an API, but because we also use Server-Side-Rendering (SSR), the final HTML is turned into this:
<div id="full-article">$real_html_content</div>
this.content = $real_html_content
This approach means that the content is repeated, once as rendered HTML, and once as a javascript variable. But in this scenario we are not using the javascript content variable. The fact that it's still included in the final HTML page means that the page size is twice as big as necessary. How can we prevent this? Is there some way of hiding/removing javascript content that has already been rendered by SSR?
Alternatively, maybe it would be better to deal with this content differently, perhaps insert it at a later stage and not involve Nuxt or SSR?
This is what you're looking for: https://github.com/maoberlehner/vue-lazy-hydration
Created by Markus Oberlehner who was seeking to avoid shipping to much JS to the frontend, especially when this was not needed.
You do have several options but this is how it can be used
<lazy-hydrate never>
<article-content :content="article.content"/>
</lazy-hydrate>
In this case, the hydration (injecting JS into static content) will never happen. There are other interesting options that can be used too!
Keep in mind that this was more of a proof of concept, hence why Markus still considers it as beta-ish. This project will probably die at some point because Vue3/Nuxt3 will be able to do this in an official way.
Still, even if I did not tried it yet, you can totally use it as of right now and enjoy a JS-light experience, it should work!

UI Automation - Elements on my UI have ember ids , which change frequently with addition of new UI elements. How to use the id for automation?

Example of the HTML of a dropdown element:
<div aria-owns="ember-basic-dropdown-content-ember1234" tabindex="0" data-ebd-id="ember1234-trigger" role="button" id="ember1235" class="ember-power-select-trigger ember-basic-dropdown-trigger ember-view"> <!---->
<span class="ember-power-select-status-icon"></span>
</div>
The xpath and CSS selector also contain the same ember id.
xpath : //*[#id="ember1235"]
css selector : #ember1235
The ember id would change from id="ember1235" to say, id="ember1265" when there is a change in the UI.
I am using id to locate the element. But every time it changes I need to modify the code. Is there any other attribute I could use for Ember JS UI elements?
There is quite a lot to discuss in your question but hopefully we will have a good answer for you #PriyaK
The first thing to mention is that Ember IDs may not be the best method to select an element in the DOM. As you have already mentioned, they can change from time to time and also it doesn't really give you a great semantic thing to select in your selenium test so it might seem a bit out of context when looking back.
One thing that you could try is to either pass a class to the ember-power-select component (the one that provides the HTML that you used in your example) and use that to select the element, something like:
<PowerSelect
#class="my-fancy-class"
as |name|
>
{{name}}
</PowerSelect>
Then you should be able to select the selected value by using the CSS selector .my-fancy-class span (because the component outputs the selected value in a span)
We just tried this in an example app but it didn't actually work 🤔 Never fear, you can also do something like this and it should work with the same selector as before:
<div class="my-fancy-class">
<PowerSelect as |name|>
{{name}}
</PowerSelect>
</div>
This is fine, but there are also a few issues using classes for selectors in tests. One example of a problem that might crop up is that your tests might all suddenly stop working if you did a style refactor and changed or removed some of the classes on your elements. One technique that has become popular in the Ember community is to use data-test- attributes on your DOM nodes like this:
<div data-test-my-fancy-select>
<PowerSelect
#class="my-fancy-class"
as |name|
>
{{name}}
</PowerSelect>
</div>
which can then be accessed by the following selector: [data-test-my-fancy-select] span. This is great for a few reasons! Firstly it separates the implementation of your application and tests from your styling and avoids the issue I described above. The second benefit of this method is that using what #Gokul suggested in the comments, the ember-test-selectors package, you can make use of these data-test- selectors in your development and test environments but they will be automatically removed from your production build. This is great to keep your DOM clean in production but also, depending on the size of your application, could save you a reasonable amount of size in your templates on aggregate.
I know you say that you are using selenium for your testing but it's also worth mentioning that if you're using the built-in Ember testing system you will be able to make use of some testing helpers that addons may provide you. ember-power-select is one of those addons that provides specific testing helpers and you can read more about it in their documentation: https://ember-power-select.com/docs/test-helpers
I hope this answers any questions you had!
This question was answered as part of "May I Ask a Question" Season 3 Episode 1. If you would like to see us discuss this answer in full you can check out the video here: https://www.youtube.com/watch?v=1DAJXUucnQU

VueJS using parent name tag inside child

Here is an example:
<input name="TESTE" id="TESTE" placeholder="TESTE">
is there a way to do that?
<div name="TESTE">
<input :name="parent.name" :id="parent.name" :placeholder="parent.name">
</div>
I dont want to do that using vue data or components. Can i do that using only pure html like example above?
Thanks!!!
Unfortunately that's not possible. You'll need to use some sort of data field for this to work. Vue renders HTML according to the data you provide it and is otherwise unaware of the properties of surrounding elements. Your best bet is to either hard-code these values or add the appropriate data fields to reference.
It's generally better practice to use the data, anyway, as it will cut down maintenance time and mitigate issues with user error.

Can I include scoped css without Vue Loader?

For a project where Vue is dropped in, is using style or similar available to components?
Vue.component('vue-sup', {
template: '<div>Sup</div>',
style: '* { color: blue; }'
})
I tried adding the styles inside the template like:
<div>
<style>
.here{}
</style>
<div>Sup</div>
</div>
which didn't work because the template parser detected a tag with side effects
Vue's implementation of scoped css is entirely a feature of vue-loader, and thus only works with compilation. Scoped css momentarily made a debut into Html 5 but saw almost no adoption and was dropped entirely as far as I know. There is the anticipation that "Shadow DOM" may be supported broadly and could be use to add scoped css, but adoption is not there yet either.
So at this point you can add unique classes or ids obviously to a parent container and scope your css that way, but is understandably not what you are asking for nor is it always practical.
The best alternative is a pollyfill. There are several that are available. Here is one by Sam Thorogood and another by Thomas Park but if you do a quick search you will likely discover more.
I came across the same problem and I'm able to insert styling inside Vue template
by creating a component that will dynamically insert a <style> tag on the DOM. This might be impractical like #skribe said but it allows me to have separate CSS from JS without using .vue extension.
You can take a look at this

RDFa Snippet Generator from GoodRelations

I've created a RDFa snippet to use on a client's website using the GoodRelations tool. The generated code creates the tags as expected, but there's no text between the divs, for instance:
<div typeof="vcard:Address">
<div property="vcard:locality" content="Yorba Linda"></div>
</div>
I'm assuming that this is OK, and that I am expected to put descriptive text for humans between the 'locality' divs without any adverse effects (in relation to SEO.) Correct?
As William says: In most cases, is is impractical to reuse visible content for publishing meta-data, because they differ in sequence or structure. In that case, it is better to put all meta-data in a single block of <div> elements without visible content. This is called "RDFa in Snippet Style", see
http://www.ebusiness-unibw.org/tools/rdf2rdfa/
Hepp, Martin; García, Roberto; Radinger, Andreas: RDF2RDFa: Turning RDF into Snippets for Copy-and-Paste, Technical Report TR-2009-01, 2009., PDF at http://www.heppnetz.de/files/RDF2RDFa-TR.pdf
Google is consuming such markup, despite a general preference for marking up visible content. Many big shops are using this approach with good results, e.g. http://www.rachaelraystore.com/Product/detail/Rachael-Ray-Stoneware-2-pc-Bubble-Brown-Baker-Set-Eggplant/316398
So if you can integrate the visible content and the RDFa constructs, then use
<div typeof="vcard:Address">
<div property="vcard:locality">Yorba Linda</div>
</div>
If you cannot, then use
<div typeof="vcard:Address">
<div property="vcard:locality" content="Yorba Linda"></div>
</div>
...
<div>
<div>Yorba Linda</div>
</div>
But the divs with invisible content must be close to the visible content and be placed better before than after the visible markup.
From and RDFa point of view, it is fine (I am assuming you are using bracers because you don't know how to escape greater than / less than characters).
The only thing you need to think about is how adding this fragment of HTML to your HTML document, will affect the rendering. Based on the fact that you are using the content attribute, this fragment is destined to remain hidden. So yo should think about this in relation to the CSS architecture. My advice would be to create a specific CSS class that is for annotations.
Having spoken to the author of Good Relations, his advice would be to put this fragment before any other HTML element in the body of your document. Generally, the Rich Snippets team indicate that they ignore hidden RDFa, but it doesn't actually matter and really in the long run it enables the publishing of RDF to anyone (not only Google) who wants to consume it.