A high-level vue application question:
A little background:
small team, still learning vue
creating a new large reasonably complex vue app from scratch
vue-cli scaffolded (vue 2, veux, router, i118n, bootstrapVue)
there are many different application entities – e.g. "user", “product”, etc.
there are many of each item, and each has a data record (from a db) that includes a number of boolean fields such as "active", “enabled”, “is_sensitive”.
item data displays in many different contexts, including: search results, table lists (e.g. browse), individual landing views for each (an item detail page), as well as ancillary lists (e.g. “A related item:”
The key problem:
In every display situation, the boolean values should to be translated from machine-friendly to people-friendly terminology.
The appropriate human-friendly term depends on the field itself (so there is no single translation for all fields).
Example:
Machine-friendly data:
[
{
name: “Megaphone”,
is_embarrassing: false,
active: false,
},
{
name: “Wankel Rotary Engine”,
is_embarrassing: true,
active: true,
},
]
Human-friendly list:
+----------------------+----------+---------------------+
| Name | Active? | Embarrassing? |
+----------------------+----------+---------------------+
| Megaphone | Inactive | Not embarassing |
| Wankel Rotary Engine | Active | Item is Embarassing |
+----------------------+----------+---------------------+
The key question:
What is the best way to solve this in a scalable, efficient, elegant, sensible way?
I have thought of a couple of options…neither of these feel scalable nor elegant,
and are brittle.
(1) sequence of in-line v-if conditions within the component view template
<p v-if=“item.property.is_embarrassing">
Item is Embarrassing
</p>
<p v-else>
Not embarassing
</p>
(2) computed properties in the component
<p>
{{ detailsPropertyEmbarrassing }}
</p>
detailsPropertyEmbarrassing() {
return item.property.is_embarrassing ? “Item is Embarrassing : “Not Embarrassing”;
},
I have also been noodling over the idea of some sort of Map that is imported along with the data and used to get the right labels, but I haven’t completely worked that out yet.
What is a solution for transforming data fields to people-friendly labels across an entire application, for a variety of different display situations?
(Side note: I may also need to transform the field in other ways, such as truncating length…)
And is there a way to establish this globally in the app in a manner that is scalable, both technically and organizationally,
so that new components can display as desired, near-automatically?
This seems like a basic fundamental need in any app of size, not just vue,
so I feel like this has been/has to have been solved before, but either I cannot find the right research keywords or am missing something obvious.
Thanks in advance!
You can think of the VueComponent as a ViewModel (or Controller if you like MVC). It's indented purpose is to fetch information from the model (backend) and transform it to something that your view can use.
Thus, the change from a boolean to a string should be done in the VueComponent and not in the view.
In your view component, declare something like myItems = []. When you fetch it, traverse the result:
backendResult.forEach(item => {
this.myItems.push({
name: item.Name,
embarrassing: item.IsEmbarrassing ? "Oh yes!" : "No"
});
Then the view is simplified:
<table>
<tbody>
<tr v-for="item in myItems">
<td>{{item.Name}}</td>
<td>{{item.embarrassing}}</td>
</tr>
</tbody>
</table>
Another solution is to use filters which requires no modification of the vue component and just a small change of the view:
<table>
<tbody>
<tr v-for="item in myItems">
<td>{{item.Name}}</td>
<td>{{item.isEmbarrassing|embarrassing}}</td>
</tr>
</tbody>
</table>
Notice the |embarrassing part in the view. It uses a filter defined as:
Vue.filter('filter', function (value) {
if (!value) return 'not embarrassing'
return 'embarrassing';
})
Related
Version info: Vuetify 2.6.3, Vue 2.6.14, Nuxt 2.15.8
I'm making a custom component that is supposed to be somewhat similar to v-autocomplete, except that it's rendered as bottom sheet. If user enters a display filter into v-text-field, the option list (v-list) is supposed to display only those options that match the filter.
In overall it works fine except one use case: let say the list has 5 items (aa, bb, cc, dd, ee) and user selected bb and cc from the list. Now, v-list-item-group's model selectedItems contains the 2 selected items bb and cc, perfect! However, when user enters b into display filter, the already selected item cc will be auto deleted from selectedItems. I can't tell if selectedItems change is caused by filter or by user selection. Is there a way to maintain the selection in model?
I'm considering a hack - if an item is selected, keep it in filteredChoices even if it does not match the filter. This behaviour is bearable but UX wise not as intuitive as the filter of v-autocomplete.
The simplified structure looks like the below:
<template>
<v-bottom-sheet scrollable>
<v-card>
<v-card-text>
<v-list>
<v-list-item-group
v-model="selectedItems"
:mandatory="!optional"
:multiple="multiple"
>
<v-list-item
v-for="item in filteredChoices"
:key="item.value"
:value="item"
>
</v-list-item>
</v-list-item-group>
</v-list>
</v-card-text>
<v-text-field
v-model="filterInput"
placeholder="filter choices..."
hide-details
></v-text-field>
</v-card>
</v-bottom-sheet>
</template>
<script>
...
filteredChoices() {
if (this.filterInput == null) {
return this.allItems
}
return this.allItems.filter((item) => {
return item.label
.toLocaleLowerCase()
.includes(String(this.filterInput).toLocaleLowerCase())
})
},
...
</script>
How I reach the solution:
I was quite new to front-end stuff. Previously, when I was learning how to implement v-model support for custom component, all web resources I came across say the same thing - bind inner component's value props to custom component's value props. However I just discovered that this is merely one of the ways rather than a must. With that new learning, more possibilities pop up in my mind and one of them lead me to below solution.
Solution:
Decouple the custom component value from bottomsheet's list
Bind the model of inner v-autocomplete to an array data, say internalValue. (this inner component is not included in question's template for simplification)
Bind the model of inner v-list-item-group (in bottomsheet) to a separate data, say bottomSheetSelections.
Update the custom component value based on user actions in bottomsheet
Add a watcher to bottomSheetSelections array:
if the array grows, it means the user has selected more item. We should push the additional item to internalValue.
if the array shrinks:
if the missing item is still there in filteredChoices, the removal is triggered by user de-selection. We should remove this item from internalValue.
else, we consider the removal is triggered by list filter. No action is needed.
Restore user selection in bottomsheet on clearing filter
Add a watcher for filteredChoices. Whenever the array grows, if the additional choice exist in internalValue, we should push it to bottomSheetSelections.
Summary
Strictly speaking, this doesn't solve the ask of question's title - the list selection in bottomsheet (bound to v-list-item-group) is still getting reset. However, at least we're able to restore it in bottomsheet on clearing filter.
More importantly, this solution achieved the objective mentioned in question details - retain the user selection value. We kept it in a separate data internalValue.
I haven't test this solution with long list of data. My guts feeling is that there could be more efficient solution. Please share it if you have a better solution.
I'm currently making bitcoin trading web app (personal project. Not a business one)
I have a bunch of cryptocurrencies prices from API, and showing it all by using v-for loop.
here's part of my code:
<tbody class="text-sm">
<tr v-for="coin in props.coins" :key="coin.code" class="hover:bg-zinc-600">
<td class="p-1">
<div class="font-semibold">{{ coin.name }}</div>
<div class="text-xs text-gray-400">{{ coin.code }}</div>
</td>
<td
class="text-right font-bold align-top p-1"
>{{ Number(coin.trade_price).toLocaleString() }}</td>
<td
:class="{ 'text-blue-400': isNegative(coin.signed_change_rate), 'text-red-400': isPositive(coin.signed_change_rate) }"
class="text-right p-1"
>
<div>{{ Number(coin.signed_change_rate).toFixed(2) }}%</div>
<div class="text-xs">{{ coin.signed_change_price }}</div>
</td>
<td class="text-right align-top p-1">{{ convertTp24h(coin.acc_trade_price_24h) }}</td>
<td class="text-right p-1">
<button class="bg-red-700 rounded-lg hover:bg-red-600 p-1">매수</button>
</td>
</tr>
</tbody>
As you can see I have many methods and expressions that converts raw value from API to human-readables.
I'm wondering if this is a bad practice. I heard that methods are called everytime so, rather use computed().
But as you can see I have my values from API in Object(props.coins) and I'm looping this object in v-for. Can I still use computed() methods to convert a value inside an Object that is also looped by v-for?
You can't use computed for items in a loop, since they don't take in arguments. Computed is used for .. computed properties and methods take in arguments e.g. formatChangeRate()
You are right that methods are called everytime, but that's totally fine and normal practice.
So creating a component with methods like formatChangeRate, formatTradePrice is totally fine.
There are ways to make it work with computed properties but in my opinion its not worth it.
1)
You coould make another component that takes in the item as a prop, uses computed property and displays it in componenent's template but that's a total overhead.
2)
You could map the array and reference it by index. Something like:
computed: {
changeRate() {
this.coins.map(coin => {
return Number(coin.signed_change_rate).toFixed(2) + '%'
})
}
}
Now changeRate is an array of formatted change rates so you could in your v-for do something like
v-for="(coin, index) in coins)">
<td>changeRate[index]</td>
So now you're looping through the array multiple times, and the code is less testable and less readable.
In my opinion using methods is totally fine and the right way to go in this example. The performance of calling a simple formatting method multiple times is negligible.
Also the cache you're refering to is that computed properties are cached based on their reactive dependency. E.g. you have in your data, firstName and lastName. You could then make a computed property called fullName that concats those two. The caching would work so that fullName doesn't change unless firstName or lastName changes.
Since you're looping through an array the value that would be computed is always changing.
you are right, methods are called everytime and in theory thats not really good, but in practice if your method just concat strings or other simple operations, that's really not a big deal. Your computer can do millions of operations like that per seconds.
In the other hand if you do complex operations then the solution is to precalculate before.
After you receive your data construct an Array looking something like bellow and use this one in your template
(pseudo code)
[{
name,
code,
changeRate: Number(signed_change_rate).toFixed(2),
...
},
...
]
We are trying to style an existing slot (SiteLinks) that contain a number of CMSLinkComponents. We are failing to obtain the full data of the components, because we are only receive the uid and typeCode when we use let-[var] syntax on the ng-template.
Are there example of how to access the full data for these components, without requesting them separately based on the uid?
<ng-template cxOutletRef="SiteLinks" let-data>
<pre>{{ data.components$ | async | json }}</pre>
</ng-template>
The context model depends on where outlets are used. In your case context is a Slot model, and on this level of hierarchy you have only list of components and not their data, because data you should get separately.
I believe, this approach will work:
<ng-template cxOutletRef="SiteLinks" let-slot>
<ng-container *ngFor="let component of (slot.components$ | async)">
<ng-container [cxComponentWrapper]="component"></ng-container>
</ng-container>
</ng-template>
cxComponentWrapper also can be helpful in cases when you need handle nested components.
This seems to remain unanswered so here is another attempt at a solution.
Currently in bootstrap-vue, I am rendering a b-table. I would like to improve this by having the ability to select a row and collapse/expand an extra div/row/etc to show further information.
In the below snippet you will see what I am trying. The problem is that I can't seem to get the expanded data to span the number of columns in the table. I have tried adding <tr><td colspan="6"></td></tr> but it doesn't seem to span like I would expect. Any workarounds for this? Thanks.
<b-table
:items="case.cases"
:fields="tableFields"
head-variant="dark">
<template
slot="meta.status"
slot-scope="data">
<b-badge
v-b-toggle.collapse1
:variant="foobar"
tag="h6">
{{ data.value }}
</b-badge>
</template>
<template
slot="#id"
slot-scope="data">
<span
v-b-toggle.collapse1>
{{ data.value }}
</span>
<b-collapse id="collapse1">
Collapse contents Here
</b-collapse>
</template>
</b-table>`
Sounds like you could use the Row Details slot:
If you would optionally like to display additional record information (such as columns not specified in the fields definition array), you can use the scoped slot row-details
<b-table :items="case.cases" :fields="tableFields" head-variant="dark">
<template slot="meta.status" slot-scope="data">
<b-button #click="data.toggleDetails">
{{ data.value }}
</b-button>
</template>
<template slot="row-details" slot-scope="data">
<b-button #click="data.toggleDetails">
{{ data.detailsShowing ? 'Hide' : 'Show'}} Details }}
</b-button>
<div>
Details for row go here.
data.item contains the row's (item) record data
{{ data.item }}
</div>
</template>
</b-table>
There is a good example in the docs at https://bootstrap-vue.js.org/docs/components/table#row-details-support
I (think) I had the same issue, and I came up with a solution which leverages the filtering functionality of the bootstrap-vue <b-table> to achieve the effect of expanding and collapsing rows.
There's a minimal example in a JSFiddle here:
https://jsfiddle.net/adlaws/mk4128dg/
Basically you provide a tree structure for the table like this:
[
{
columnA: 'John', columnB:'Smith', columnC:'75',
children:
[
{ columnA: 'Mary', columnB:'Symes', columnC:'46' },
{ columnA: 'Stan', columnB:'Jones', columnC:'42' },
{ columnA: 'Pat', columnB:'Black', columnC:'38' },
]
}
]
The tree is then "flattened" out to rows which can be displayed in a table by the _flattenTreeStructure() method. During this process, the rows are also annotated with some extra properties to uniquely identify the row, store the depth of the row (used for indentation), the parent row of the row (if any) and whether or not the row is currently expanded.
Once this is done, the flattened structure can be handed to the <b-table> as it is just an array of rows - this is done via the computed property flattenedTree.
The main work now is done by the _filterFunction() method which provides custom filtering on the table. It works off the state of the expandedRowIndices property of the filterObj data item.
As the expand/collapse buttons are clicked, the row index (as populated during the flattening process) is inserted as a key into expandedRowIndices with a true or false indicating its current expanded state.
The _filterFunction() uses this to "filter out" rows which are not expanded, which results in the effect of expanding/collapsing a tree in the table.
OK, so it works (yay!), but...
it's not as flexible as the base <b-table>; if you want to show different columns of data, you'll need to do some work and to re-do the <template slot="???"> sections for the columns as required.
if you want to actually use filtering to filter the content (with a text search, for example) you'll need to extend the custom filter function to take this into account as well
sorting the data is not something I had to do for my use case, and I'm not sure how it would work in the context of a tree structure anyway - maintaining the tree's parent/child relationships while changing the order of the rows around would be... fun, and I suspect this would be a nice challenge to implement for someone who is not as time poor as me. ;)
Anyway, I hope this is of use to someone. I'm reasonably new to Vue.js, so there may be a better way to approach this, but it's done the job I needed to get done.
The problem
In Vue, I'm passing an array called issues. The array contains (at present) two objects, but can contain infinite amounts of objects. Every object then has another array named issues, nested inside of it.
The issue is that when I need to display the data, I find that I can't seem to reach the inner "issues" section of it.
I can loop through the first array like so:
<tr v-for="issue in issues" track-by="id">
But that only lets me see the first two objects. I then tried:
<tr v-for="issue in issues" track-by="id">
<td>
<div class="btn-table-align" v-for="issue_title in issue.issues">
#{{ issue_title.title }}
</div>
</td>
</tr>
Which lets me access the sub-elements, but doesn't generate enough rows. I then tried looping over it AGAIN, like so:
<div v-for="first in issues" track-by="id">
<tr v-for="issue in first" track-by="id">
<td>
<div class="btn-table-align">
#{{ issue.id }}
</div>
</td>
</tr>
</div>
But, alas - it generates no rows at all when I do that.
I'd basically need a way to run a "issue in issues", then another for the results and THEIR direct children. The only issue is - I can't figure out how to do it, and Vue won't respond to any of the above attempts! I find a severe lack of documentation on two-dimensional arrays in Vue as well, which has me confused further.
Can anyone shed some light on this? Is it possible, or do I need to adjust the data sent to Vue differently?
To help, I shot an image of an example structure: http://i.imgur.com/6Oz67R9.png
This was a typical 5am question, where I now realize that the data I'm passing makes no sense - it should be the other way around. The actual issues should be in the first array, and the subarray should contain affected servers.