I have my
v-html="customButtons"
and I want to insert in this v-html a v-on:click with custom function like this
<div class="v-m-button">
<button type="button" id="btn-cancel" class="btn btn-sm btn-success"
v-on:click="saveButtonClick()">
<span>Save</span>
</button>
</div>
^code above will be pass to customButtons v-html tag
help me with this thanks!
I ran into the same issue and here are the solutions I found:
On Vue 2, there is this article that might help some people: https://www.programmersought.com/article/53615036178/
On Vue 3, there is this library over there, that I used with success.
However, as mentioned by others elsewhere there are a good reasons why this is made so hard to do. Maybe the security reasons are not a big concern for you. But say that your app grows and is so widely used that performance becomes your main concern; then you may want to rebuild your front-end using Svelte instead of Vue. Then, all your #click=this... (vue specific code) in the html sent by you API will become almost unusable by the Svelte app, at which point you might tell to yourself:
"It would have been way simpler to just send those as json metadata and build the appropriate interface instead of trying to 'win time' by brute-forcingly favoring a bad data structure."
Related
<div v-html="this.getNormalMessage()"></div>
We are using "vue": "^2.5.17". While running a sonarqube report we got these hotspots "Make sure bypassing Vue built-in sanitization is safe here." for the above code snippet. Using v-html is causing this hotspot in sonarqube report. getNormalMessage is function which returns htmlContent.
we tried the solutions like
<div>{{ getNormalMessage }}</div>
but these solutions are converting content into a plain text. In our case we needed it to be rendered as html.
Do we have better solutions ?
As mentioned here, you can use vue-dompurify-html.
Be careful, only the v2.5.2 has still Vue2 support, then it's dropped.
Dynamic multilingual sites from the backend to the replacement of large sites
I changed the language, but this time I am trying for the first time to do it at the front desk (Nuxt.js + i18n).
<a href="https://gooogle/en.com" data-link="fugafuga">
Without using nuxt-link
<template>
<a href="https://gooogle/｛｛t('locale')｝｝.com" data-link="｛｛t('hogehoge')｝｝" >
</template>
Is it possible to divert and use a tag as it is?
(In the above writing method, an error occurred and it was useless, so please teach me a workaround)
I18n t method wrapped in quotes in inside tag quote
How do I write it?
Such a shape is desirable because the scale is too large
We apologize for the inconvenience, but we would appreciate it if you could teach us.
thank you.
Suggested fix:
<template>
<a :href="`https://google/${t('locale')}.com`" :data-link="t('hogehoge')"></a>
</template>
You can read more about data binding with Vue/Nuxt here: https://v2.vuejs.org/v2/guide/class-and-style.html#Object-Syntax
I'm building a Single Page Application using, Vue, Vue-router and Vuex. I've tried to implement Algolia Instantsearch vuejs, but I'm having some issues. Since my app is using a lot of nested components, I'm having a hard time figuring out how to structure this one.
This is the basic structure:
- App
- Header (this is where the search input is placed)
- Content
- Search (this is where the refinements and results are shown)
- Footer
I've read the documentation, but I might have missed something. Let's say the user is on the homepage, when starting typing into the searchinput in the Header component. I then use vue-router to go to /search, but this doesn't seem to work?
I don't know how to do this? As from what I can understand, the documentation only show you how to sync with vue-router and now how to handle my scenario.
I believe this is a fairly common use case for instantsearch, but I couldn't find anything searching through Google. Maybe because, I don't know how to describe the issue.
I hope you can help.
Thanks!
If you use the latest version of vue-instantsearch, you may use ais-configureas describe by https://www.algolia.com/doc/api-reference/widgets/configure/vue/.
<ais-instant-search :index-name="indexName" :search-client="searchClient">
<ais-configure :query="query" />
<ais-hits>
<div slot="item" slot-scope="{ item }">
<h2>{{ item }}</h2>
</div>
</ais-hits>
</ais-instant-search>
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.
I just come across a good write up for a new ASP.NET Core feature called Tag helpers.
From there, I understood that one can replace the following code:
#model MyProject.Models.Product
#using (Html.BeginForm())
{
<div>
#Html.LabelFor(m => p.Name, "Name:")
#Html.TextBoxFor(m => p.Name)
</div>
<input type="submit" value="Create" />
}
with:
#model MyProject.Models.Product
#addtaghelper "Microsoft.AspNet.Mvc.TagHelpers"
<form asp-controller="Products" asp-action="Create" method="post">
<div>
<label asp-for="Name">Name:</label>
<input asp-for="Name" />
</div>
<input type="submit" value="Save" />
</form>
There's some new syntax such as asp-controller, asp-for, etc. But what does it do? And what's the advantage of this new approach?
The most important improvement I've seen so far is the control it guarantees over your HTML elements. While convenient, the Html helpers used by MVC create problems when you try to do things they weren't built for.
A simple example can be seen when using the TextBox in MVC5:
#Html.TextBoxFor(m => p.Name)
The resulting HTML markup looks like:
<input class="form-control" id="Name" name="Name" type="text" value="">
Nice and simple. But what if you want to add a placeholder attribute? What if you want to use bootstrap's validation states? What if you have some 3rd party super cool javascript library which needs custom attributes. None of these things were possible in the initial release of MVC5. Though they were eventually added via update in the form of htmlAttributes. Even now adding custom attributes is kludgey at best.
#Html.TextBoxFor(m => p.Name,
new {#class="form-control has-error", placeholder="Enter Name",
superCoolFeature="Do something cool"})
While you could argue this is still less code that straight HTML, it is no longer a significant advantage. Worse, this solution still doesn't cover dashes in attributes which are fairly common. If you need them you are stuck with a workaround such as ActionLink htmlAttributes
I've gone down the route of fixing these deficiencies with custom editors, and tried building my own TextBox controls. It became obvious pretty quickly that replacing the included TextBox templates would require a lot of work. Worse, your templates have to have knowledge of any extensions you are adding to use them.
It seems like the inclusion of Bootstrap and other 3rd party tools into MVC have made it more obvious that the current design has problems with extending HTML which need to be fixed. Hopefully the tag helpers implementation is complete enough that we can avoid them in the future.
Not to mention, your Web Designers will have real HTML tags to edit that they recognize to re-design your pages. Designers shouldn't have to be coders and there's enough for these sharp folks to keep up with, studying the moving targets of HTML5 and CSS3 specs.
A few things come to mind:
As #ChrisWalter points out, these tag helpers give HTML tags an Open/Closed quality. Rather than just letting you write extension methods for common HTML patterns, you can extend an HTML element. This lets you pick-and-mix multiple extensions per component, rather than having to choose between them.
HTML Helpers tend to not work super well for elements that need to have inner HTML provided as an argument. They came up with a clever pattern so you can say:
#using (Html.BeginForm(...)){
{
<input ... />
}
But there's nothing about BeginForm() that would force you to put it in a using statement, and there's nothing to prevent you from using incorrect HTML structure. (<input> technically isn't allowed to be directly inside a <form> tag.)
This gives us a really easy transitional stepping stone into the Web Components world of HTML5. A component that you write today for jQuery or Bootstrap to pick up and enhance may make more sense as an Angular 2 or Polymer component in a few years. Using HTML syntax makes it possible to write your HTML the way you want it to look when it's a web component, and have it automatically translated into the structure it has to take on for now (or for specific browsers, later).
Accepted answer is correct but just a correction.
Html Helpers cover dashes in attributes by use of underscore. for example if you want html like
my-attr=value
then you can use html helpers like
#Html.TextBoxFor(m=>m.id,
new { my_attr = value })
then it will convert accordingly.
I know the original question asks about advantages but for the sake of completeness I have to mention one disadvantage:
With tag-helpers enabled you cannot inject C# code inside tag attributes.
I.e. this code will break:
<!-- this won't work -->
<input class="#GetMyClass()">
<!-- this won't work too -->
<input type="checkbox" #(condition ? "checked" : "") >
To work around this problem you can use custom tag helpers or just disable tag helpers altogether like described in this answer: https://stackoverflow.com/a/65281018/56621
P.S. My humble opinion that can be safely ignored: tag helpers are "magic". And "magic" is always bad in programming. If something looks like an HTML tag, walks like a tag and quacks like a tag - then it should probably be an HTML tag. Without me knowning "oh, it's not *really* a tag".
From building a basic web app from the ground up in .NET 7/Razor pages, I haven't encountered a single instance where a tag helper has an advantage over simply coding the HTML. I don't come from an MVC background so maybe that is where the advantage lies but as seen before...Microsoft has released yet another version of wheel-reinvention that instead of making things easier for some simply adds more confusion to others.