recently in the refactoring project, I saw such a structure in the code. I want to optimize it. I don"t know what appropriate ways to write it.
<li class="card-wrap" v-for="(item, idx) in orderList" :key="idx" @click="toDetail(item)">
<div class="card">
<div class="card-hd">
<div class="text-shop">
<span>{{item.info.merchant}}</span>
<span class="text-state text-danger clearfix" v-if="item.status === 1 && parseFloat(item.payment_amount) !== -1"></span>
<span class="text-state" v-else-if="item.status === 3 || item.status === 6 && parseFloat(item.payment_amount) !== -1"></span>
<span class="text-state" v-else-if="item.status === 5 && parseFloat(item.payment_amount) !== -1"></span>
</div>
<div v-if="parseFloat(item.payment_amount) !== -1" class="text-transform font-tp-m">
<span>{{item.payment_type==1 ? parseFloat(item.payment_amount).toFixed(4) : parseFloat(item.payment_amount).toFixed(2) }} {{"paymentTypeName.name"}}</span>
<i class="icon-conversion"></i>
<span>{{item.payment_type==1 ? parseFloat(item.payment_amount).toFixed(4) : (parseFloat(item.payment_amount)/parseFloat(item.ex_rate)).toFixed(8)}} {{item.address.type}}</span>
</div>
<div v-else class="text-transform font-tp-m">
<span>{{parseFloat(item.payment_amount_settled).toFixed(4)}} {{item.address.type}}</span>
</div>
<div class="text-pay-state">
<div>
<p class="desc">
<span class="font-tp-m content">{{parseFloat(item.payment_amount_settled).toFixed(8)}}</span>
<span class="font-tp-m content">{{item.payment_type === 1 ? item.address.type : "paymentTypeName.name"}}</span>
</div>
<div>
<p class="desc">
<span class="font-tp-m content">{{parseFloat(item.payment_amount_unsettled).toFixed(8)}}</span>
<span class="font-tp-m content">{{item.payment_type === 1 ? item.address.type : "paymentTypeName.name"}}</span>
</div>
</div>
</div>
</div>
</li>existing problems:
- there are several v-if v-else-if in which there are many condition judgments, which are not intuitive .
- uses a lot of parseFloat (number) .tofixed (n), and some values have to be distinguished according to payment_type. Sometimes they are displayed directly, and sometimes they are calculated and displayed according to the existing values. And I have seen many pages with such a similar structure. Can there be a unified and elegant way to write them?
- and my colleagues in the background developer told me that I cannot display these data directly, because the data returned by the background may have negative numbers, and if there are any negative numbers, they should be displayed as 0 .