前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >JavaScript移除对象中不必要的属性

JavaScript移除对象中不必要的属性

作者头像
奋飛
发布于 2021-10-25 02:01:31
发布于 2021-10-25 02:01:31
2.3K00
代码可运行
举报
文章被收录于专栏:Super 前端Super 前端
运行总次数:0
代码可运行

Thinking系列,旨在利用10分钟的时间传达一种可落地的编程思想。

业务开发中,我们经常会遇到:基于后端返回接口数据,前端保存到对象 Object 中,前端开发过程中为了一些场景的便利性,需要在该对象中增加相应的属性,但这些属性对于后端没有意义,保存提交时希望删除掉。

真实业务代码:保存前需要删除对应的 *Value 字段

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
async saveData (type, data) {
  // 提交时删除多余字段
  delete data.isCommonValue
  delete data.isRemoteValue
  await this.$request({
    ...API.EDIT_SERVICE,
    method: type === 'add' ? 'post' : 'put',
    data
  })
}

上述是大家普遍的写法,但部分场景下上述写法并不是最优写法,且可能会带来一些副作用。下面通过 示例 的方式阐述一下:

示例

为了更好的展示上述情况,我们重新编写示例(仅为说明实现)。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
let person = {
  id: '001',
  name: 'ligang', 
  email: 'xxx@x.com'
}

诉求:在提交给后端时,需要删除 email 字段。

方式一:delete 删除

同上述给到的业务代码处理方式一样

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
delete person.email
console.log(person)	// {id: '001', name: 'ligang'}

原数据中的相关属性也会删除掉。

Reflect.deleteProperty() 允许用于删除属性,同上述 delete 行为一致。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
Reflect.deleteProperty(person, 'email')
方式二:解构

形成新的对象,避免在引用原始对象的地方产生副作用。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
let {id, name} = person
let newPerson = {id, name}
console.log(newPerson) // {id: '001', name: 'ligang'}

会和原数据切断引用。对于保留属性个数少,该方式处理简单且易懂;保留属性过多的场景会比较复杂。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
let {email, ...newPerson} = person
console.log(newPerson) // {id: '001', name: 'ligang'}

会和原数据切断引用。对于保留属性个数多,该方式处理简单且易懂;保留属性过少的场景会比较复杂。

总结

实际使用中,强烈建议方式二来操作,不要影响原数据。特别是在mvvm框架中,原数据往往是响应式的,delete/deleteProperty 意味着切断“响应关系”,delete 操作之后的数据响应就会有问题。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
data () {
  return {
    person: {
      name: 'ligang',
      email: 'x@x.com'
    }
  }
},
methods: {
	deleteProp () {
  	delete this.person.email
    // this.$delete(this.person, 'email')
	},
  addProp () {
  	this.person.email = 'xxx'
    this.$set(this.person, 'address', 'xxx')
  }
}
  1. 执行 delete 操作,js 对象属性剔除掉了,但页面没有及时响应,可以使用 vue 中的 this.$delete() 确保删除能触发更新视图
  2. 执行 add 操作,重新添加 email 及 address 属性
    • this.person.email = 'xxx' 并不具备响应式
    • this.$set(this.person, 'address', 'xxx') 具备响应式

补充

对于已经创建的实例,Vue 不允许动态添加根级别的响应式 property。下述方式都无效!-- vue reactivity object

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
this.$set(this, 'email', '')
this.$set(this.$data, 'email', '')
本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2021/10/24 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
重构:改善饿了么交易系统的设计思路
这篇文章成型于交易系统重构一期之后,主要是反思其过程中做决策的思路,我没有使用「架构」这个词语,是因为它给人的感受充满权利和神秘感,谈论「架构」让人有一种正在进行责任重大的决策或者深度技术分析的感觉。
用户1516716
2019/09/24
4340
重构:改善饿了么交易系统的设计思路
.NET领域驱动设计—初尝(原则、工具、过程、框架)
原则对于任何一项技术实现来说都是至关重要的,在设计某一个系统功能的时候我们讲究的是设计原则:
王清培
2019/03/01
8480
.NET领域驱动设计—初尝(原则、工具、过程、框架)
重温设计模式系列(三)面向对象设计原则
面向对象基础知识,只是给了我们一个概念,如何更好的设计出良好的面向对象代码,需要有设计原则作为支持。设计原则是核心指导思想,在这些原则的基础上,经过不断的实践,抽象,提炼逐步产生了针对特定问题的设计模式。因此,学好设计模式的基础是掌握基本的设计原则。本文将介绍面向对象常用的设计原则。(某些原则,也可以用在系统级,模块级等类型的设计中应用)
架构之家
2022/07/12
3590
重温设计模式系列(三)面向对象设计原则
万字多图 | UML 入门指南
谈到面向对象技术的分析和设计,自然就离不开 UML。对于 UML 这个概念,很多程序员朋友耳熟能详,也有在用,但在工作中,一些朋友其实并不擅长使用 UML 甚至对 UML 这个东西模棱两可,也包括我自己。因此我希望可以结合自己的经验和实践,写一篇 UML 的入门文章,帮助做面向对象的程序员朋友能更好的利用它,从而顺利完成自己的编程设计工作。
蜗牛互联网
2021/02/26
8810
万字多图 | UML 入门指南
面向对象设计原则
迪米特法则来自于1987年美国东北大学一个名为“Demeter”的研究项目。 迪米特法则要求一个软件实体应当尽可能少地与其他实体发生相互作用 应用迪米特法则可降低系统的耦合度,使类与类之间保持松散的耦合关系。 迪米特法则要求在设计系统时,应当尽量减少对象之间的交互 。如果两个对象之间不必彼此直接通信,那么这两个对象就不应该发生任何直接的相互作用 。如果其中一个对象需要调用另一个对象的方法,可以通过“第三者”转发这个调用 * 通过引入一个合理的“第三者”(中间类)来降低现有对象之间的耦合度。
泰斗贤若如
2020/03/03
7190
DDD在大众点评交易系统演进中的应用
本文主要涉及境外出行、商场团购和内容商业化等三类交易业务场景。在大众点评App里,在境外城市站有美食、购物、商场、景点、门票、当地玩乐等频道入口,可以购买境外出行交易产品,在境内的逛街/商场频道可以找到商场团购优惠以及商场团购代金券。
美团技术团队
2024/05/15
2360
DDD在大众点评交易系统演进中的应用
面向对象架构设计流程
软件架构:与"设计模式"类似,基于"领域架构",应用架构设计原则和方法,精雕细琢,逐步迭代,得出最终的软件架构。
别明天就今天吧
2020/09/07
6230
架构设计方法论
业务分析阶段是由业务分析师 基于自身的业务知识和类似产品的参考,再结合客户、领域专家的咨询和指导输出业务分析阶段的成果,主要包括 领域模型 和 业务模型
JAVA日知录
2021/04/07
1.6K0
架构设计方法论
面向对象的代码风格(下)
面向对象代码的结构 在结构化编程中,代码的结构以分解流程,实现处理方案为核心,代码的分解原色是以实现步骤为主。理解这种结构的代码,我们需要先理解问题的解决方案,如果需求变化,一般都需要修改代码。面向对象思想,针对结构化编程的这些缺点,提出了著名的“开-闭”原则。意思是代码应该对添加开放,对修改关闭。能做到这个原则,是需要代码结构上利用面向对象的特性才能做到的。 面向对象代码结构的重点是定义“类”,与结构化编程倾向分解问题解决步骤不同,面向对象编程更重视描述问题本身。由于代码按“类”划分,所以一般不会完全解决
韩伟
2018/03/05
7800
面向对象的代码风格(下)
面向对象设计原则
某软件公司开发人员针对CRM(Customer Relationship Management,客户关系管理)系统中的客户信息图表统计模块提出了如图所示的初始设计方案。
千羽
2021/12/29
4410
面向对象设计原则
[C++设计模式] 深入理解面向对象设计原则
在软件开发中,变化是永恒的主题。当需求发生变化时,设计的灵活性和可扩展性便成为系统能否持续演进的关键。设计模式的核心就在于利用面向对象设计原则,帮助开发者构建既能应对变化又具有高度复用性的系统。
DevKevin
2024/12/04
1740
万字长文,结合电商支付业务一文搞懂DDD
作者范钢,曾任航天信息首席架构师,《大话重构》一书的作者。本文结合电商支付场景详细描述了领域驱动模型的实际应用。
用户7927337
2020/11/30
1.3K0
万字长文,结合电商支付业务一文搞懂DDD
面试官亲述:如何利用设计模式改善业务代码
在业务部门的开发中,大多数的我们在完成的业务的各种需求和提供解决方案,很多场景下的我们通过 CRUD 就能解决问题,但是这样的工作对技术人的提升并不多,如何让自己从业务中解脱出来找到写代码的乐趣呢,我做过一些尝试,使用设计模式改善自己的业务代码就是其中的一种。让代码变得更加简洁和提升健壮性,从代码中寻找一些欢乐。
程序员白楠楠
2021/01/07
4380
领域驱动设计概览
领域驱动设计(Domain Driven Design,DDD)是由Eric Evans最早提出的综合软件系统分析和设计的面向对象建模方法,如今已经发展为一种针对大型复杂系统的领域建模与分析方法。它完全改变了传统软件开发工程师针对数据库进行的建模方法,从而将要解决的业务概念和业务规则转换为软件系统中的类型以及类型的属性与行为,通过合理运用面向对象的封装、继承、多态等设计要素,降低或隐藏整个系统的业务复杂性,并使得系统具有更好的扩展性,应对纷繁多变的现实业务问题。
张逸
2018/10/24
8610
领域驱动设计概览
《解构领域驱动设计》第二章
应对复杂度的挑战,或许是构建软件的过程中唯一亘古不变的主题。为了更好地应对软件复杂度,许多顶尖的软件设计人员与开发人员纷纷结合实践提出自己的真知灼见,既包括编程思想、设计原则、模式语言、过程方法和管理理论,又包括对编程利器自身的打磨。毫无疑问,通过这些真知灼见,软件领域的先行者已经改变或正在改变我们构建软件的方法、过程和目标,我们欣喜地看到了软件的构建正在向着好的方向改变。然而,整个客观世界的所有现象都存在诸如黑与白、阴与阳、亮与暗的相对性,任何技术的发展都不是单向的。随着技术日新月异向前发展,软件系统的复杂度也日益增长。中国有一句古谚:“道高一尺,魔高一丈。”又有谚语:“魔高一尺,道高一丈。”究竟是道高还是魔高,就看你是站在“道”的一方,还是“魔”的一方。
张逸
2023/03/23
7230
《解构领域驱动设计》第二章
60条面向对象设计原则
60条面向对象设计原则 你不必严格遵守这些原则,违背它们也不会被处以宗教刑罚。但你应当把这些原则看成警铃,若违背了其中的一条,那么警铃就会响起。   —–Arthur J.Riel   (1)所有数据都应该隐藏在所在的类的内部。   (2)类的使用者必须依赖类的共有接口,但类不能依赖它的使用者。   (3)尽量减少类的协议中的消息。   (4)实现所有类都理解的最基本公有接口[例如,拷贝操作(深拷贝和浅拷贝)、相等性判断、正确输出内容、从ASCII描述解析等等]。   (5)不要把实现细
用户1289394
2018/02/26
8430
聊聊领域驱动设计
DDD全写 domain driver design ,也称为领域驱动设计。大型复杂业务系统架构一般都会用到,在提高系统扩展性有很大帮助。
微观技术
2020/08/20
7810
【愚公系列】2023年11月 面向对象设计原则(六)-合成复用原则(Composite Reuse Principle or CRP)
面向对象设计原则是一些通用的软件设计原则,用于指导软件设计人员开发高质量、可扩展、可维护的软件系统。这些原则的作用如下:
愚公搬代码
2023/11/27
2650
领域驱动设计-上
随着软件系统越来越庞大,需求越来越模糊,代码越来越混乱,测试越来越困难,技术演进基本不可能,而其中大型复杂的软件项目更容易走向系统老化的过程,形成需求难、开发难、测试难、创新难,单体架构局部业务膨胀可以拆成微服务,那么微服务局部业务膨胀又应该怎么做?DDD之所以火,即能解决微服务解决不了的问题。DDD是为了解决快速变化、复杂系统的设计问题。
用户7353950
2022/06/23
4880
领域驱动设计-上
我是怎样教媳妇面向对象编程的
简介 我老婆 Farhana 想要继续软件开发生涯(之前因为我们的第一个孩子出生,她不得不放弃)。我已经有了一些软件设计和开发的经验,所以这几天我就在试着帮助她学习OOD。 由于我早年在软件开发的经验,我总是发现无论一个技术问题看上去多么难搞,只要从现实生活的角度去解释或用对话的方式去讨论总能让它变得更简单。关于OOD,我们已经有了许多成果丰硕的讨论,我觉得有人可能发现这是一个学习OOD有趣的方式,所以我想我应该分享出来。 下面是我们的谈话步骤:话题:介绍面向对象设计 丈夫:亲爱的,让我们开始学习面向对象设
Java高级架构
2018/04/19
8370
我是怎样教媳妇面向对象编程的
推荐阅读
相关推荐
重构:改善饿了么交易系统的设计思路
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档