体验ChatGPT在具体应用场景下的能力与表现——vuedraggable的move多次触发问题

这篇具有很好参考价值的文章主要介绍了体验ChatGPT在具体应用场景下的能力与表现——vuedraggable的move多次触发问题。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

当下人工智能模型在满天飞,今天拿一个具体的应用场景,来体验下ChatGPT的能力与表现,看看是否能解决实际问题。
顺便填一下之前遇到的一个具体的坑:vuedraggable的move多次触发问题。

背景

背景是这样的,实现低代码开发平台过程中,使用vuedraggable组件,通过拖拽式操作实现属性配置功能。如下图所示:
体验ChatGPT在具体应用场景下的能力与表现——vuedraggable的move多次触发问题
获取到业务实体的属性列表,放到最左侧,然后,通过拖动的方式,将某个属性,设置为查询条件或查询结果。

问题

当时留了一个坑,要解决的是如何处理属性重复添加问题,大致情况如下:
vuedraggable只要拖放,立马就能看到效果,例如,从左侧实体属性列表,拖放到右侧查询条件。但在这个场景下,实际上,需要判断下右侧属性列表是否已存在,如不存在,则允许添加,如存在,则不再添加。后端的验证处理是小case,就不在这里多说了,关键是前端该怎么处理。

看了半天官方文档,没找到合适的控制,又百度了半天,也没有满意的结果,自行摸索,终于发现move事件可以用。实际上,官方对于move的定位,是用来自定义控制那些元素可以拖拽或不允许拖拽并控制是否允许停靠的。我们这里就是希望控制是否允许停靠。

首先,一个坑点是,move虽然是事件,但不是我们常用的,用@move='move’来触发,而是使用了属性绑定的方式,用:move=‘move’,这点有点反常理,我就卡了一会,发现事件不触发,详细看文档才发现问题在这。

其次,在我们这个场景下,move属性,绑在左侧实体属性组件,还是右侧查询条件组件上,从是否允许停靠描述看,好像应该放到右侧,但实际测试发现,从左侧拖到右侧,根本就不触发,因此这个move,实际是针对源列表而言的。

再次,实际测试发现,存在触发多次问题,怀疑跟前端的事件冒泡机制有关,摸索了半天,也没找到只触发一次的办法。

// 移动
    move(e) {
    // TODO 存在触发多次问题    
    const code = e.draggedContext.element.code
    const list = e.relatedContext.list
    const exist = list.some(item => { return item.code === code })
    // if (exist) {
    //   this.$message.info('已存在,请勿重复添加')
    // }
    return !exist
    }

详见https://blog.csdn.net/seawaving/article/details/128083596

测评过程

这篇帖子大概是2022年12月份发布的,到现在4个多月,也没见有人评论告知如何解决。
输入关键词搜索,下图是百度结果……排名第一位的居然是我自己的博文……不得不说,CSDN的权重还是很给力的。
搜索结果看了下,还是没有问题的答案。
image.png
之前零星用过ChatGPT,大都是第三方封装的,限量使用,只能问有限的问题,并且经常出现繁忙的答复。今天发现一个不限量使用的客户端工具,也不需要OpenAI的key,于是装上了,正好借这个场景来测试下。

第一回合

先来点开胃小菜,试试ChatGPT的智能化程度,能不能正确理解问题并给出有效答复。
第一个问题:如何实现vue中的拖拽功能
回答结果如下:
首先,直接就推荐了vuedraggable,并且提供了该组件的安装命令
image.png
然后提供了使用的示例代码。
image.png
最后还给了示例的说明。
image.png
上面三张截图是一个问题和一个回答,一气呵成,并没有中途附加追问,这回答简洁直观,实用性很强。

接下来,我看上面的例子是对于vue2.0的,然后追加了一句,在vue3.0如何实现,结果是跟上面给的结果完全一样。
作为一名从vue2.0升级到vue3.0的开发者,清晰的知道vuedraggable在新旧版本的用法是有差异的,vue2.0的用法在vue3.0中会报错。vue3.0引入了名字为item的插槽,用法如下:

      <draggable v-model="list" item-key="index">
          <template #item="{ element }">
           {{ element.name }}
          </template>
        </draggable>

于是追问了一句:vue3和vue2中vuedraggable的用法一样吗?
image.png
结果还是不理想,在ChatGPT的认知里,vuedraggable在Vue2.0和Vue3.0用法是完全一样的。

总结:能正确理解问题,并给出简洁实用的答复,但答案不一定准确。虽有瑕疵,但总体来说表现不错。

第二回合

回归正题,也就是要填的坑,开问:vuedraggable的onMove如何解决多次触发问题
image.png
给出的答案是个惊喜,ChatGPT知道这里存在坑:

在Vue.js中使用vuedraggable时,onMove事件会在拖动元素时多次触发,这可能会导致性能问题。

更为惊喜的是,直接给出了解决方案,还一次性给了俩:

为了解决这个问题,可以使用throttle或debounce函数来限制事件的触发次数。
throttle函数可以在一定时间内限制函数的调用次数,而debounce函数可以在函数最后一次调用后一定时间内才会再次调用函数。这两个函数都可以有效地解决onMove事件多次触发的问题。

并且对于第一个解决方案,给了示例代码:

import { throttle } from 'lodash';

export default {
  methods: {
    handleMove: throttle(function(event) {
      // 处理拖动事件
    }, 100)
  }
}

并给了方法的使用说明,以及参数含义:

在这个示例中,handleMove方法使用throttle函数来限制onMove事件的触发次数。throttle函数的第二个参数是时间间隔,单位是毫秒。在这个示例中,事件将在100毫秒内最多触发一次。

我以前没用过throttle函数,虽然从示例代码推测可能是一个名字为lodash的包提供的,但并不能确定,于是追问了下,vue中method区域使用throttle,回答如下:
image.png
这可比搜索引擎强多了,直接给出安装脚本。如果按照常规方式,得先百度,然后从搜索结果里逐条查看,哪条是自己需要的。这个过程中还需要去伪存真……现在同样内容转发太多了,自己不做验证,以讹传讹的情况非常常见。

这里给的方案,只是减少调用频率,并没有实现只触发一次的终极目的。既然已经到这里了,进一步逼下ChatGPT,看看是否有潜能。
image.png
给出的方案依旧是上面的,不理想,再追问了一下。
image.png
用上面这种方法试了下,确实只会触发一次,但问题在于,从左侧属性列表中刚开始拖动,尚未到右侧查询条件区域就触发了,结果就是导致拖拽功能直接异常了,即拖放失效,无法添加属性。

上面这个回答,实际脱离了vuedraggable的move事件处理了,于是结合起来问,结果还真给出了新方案:
image.png
不过,方案虽然是新的,实际跟第三方的once函数的机理差不多,效果也差不多。

实际上,这里ChatGPT提供的方案还有个错误,就是move是一个属性,而不是事件,用:move而不是@move来绑定,因此这种方案vue解析直接会出错。

回过头来思考了一下这个问题,如果想从根源上实现属性在列表中拖动,只触发一次效果,那应该是vuedraggable组件提供相应的事件,即拖动到指定位置后松开鼠标左键时触发。

vuedraggable组件有end事件,但是这个事件不像move,返回false可以取消操作,而是一定会成功,即从前端看,把一个属性,从左侧列表拖到了右侧列表,无论右侧列表是否已存在。虽然可以从后端去验证和处理,并刷新右侧列表,但不可避免还会出现先出现后消失的闪烁情况,效果并不好。

当初就是发现end事件不能取消拖拽,才拿move作为曲线救国方案来实现的。因此,当下最优解决方案,实际就是使用throttle函数,来减少触发次数,经反复试验,将间隔时间设置为500毫秒比较合适,能大幅减少触发次数,且不会让拖拽操作显得卡顿。

顺便提一下,期待vuedraggable组件将来能改造下end事件,变成可取消。

补一点后续:
第二天再次尝试提问,给出了一个新的解决方案
体验ChatGPT在具体应用场景下的能力与表现——vuedraggable的move多次触发问题
测试了下,对于我的当前场景跨列表拖动并有没有效果,实际是用于单组件内部拖动控制的。

总结:聚合处理后的结果远优于搜索引擎,节省了人工查看分析结果的成本,答案基本靠谱。

第三回合

下面进入深度测评,针对信息有误的情况,看看是否能通过回答来纠正ChatGPT的认知。
就以vuedraggable组件的move是属性还是事件来提问。
先问下,vuedraggable的事件有哪些,回答如下:
image.png
可以看到,并不包含move。

但是,再提问vuedraggable的move如何使用
image.png
答复却是把move定义为事件,给出的绑定方式是@move,明显是前后矛盾的。
为什么会出现这个问题?推测情况可能有两种,一是vuedraggable组件的某些版本可能确实将move作为事件而不是属性处理的;二是网上转发,自己不做验证,以讹传讹的太多了,导致ChatGPT输入了大量错误结果而出现了认知错误。具体是哪一种,我也不知道:)。
image.png
咱们试着通过修正下
image.png
ChatGPT响应了修正,然后重复问一下:
image.png
ChatGPT记住了之前的修正,再重新问下
image.png
换个问法,ChatGPT也输出了修正后的结果,理解并记住了。
把开始的问题再问一遍
image.png
答案跟最初相比发生了变化,不过产生了前后不一致的情况,一方面接受了move是属性的说法,另一方面,还残留着通过@move来监听变化的描述。

隔了一天,再次问同样问题:
体验ChatGPT在具体应用场景下的能力与表现——vuedraggable的move多次触发问题这次很明确给出move是属性而不是方法了。

此外,我不确定我通过答案修正的生效范围,是仅对我的账号生效,还是对整个模型生效,应该是后者吧。换个角度,如果再次输入大量错误的结果,ChatGPT是否会再次把move当成事件而不是属性呢?

总结:可通过交互修正问题答案,具备自我学习和更新能力。

第四回合

本来前面三个回合已经结束了,还是惦念完美解决方式,想从vuedraggable的end事件入手。于是隔了几天,再次提问,发现ChatGPT给出来不同的解决方案,经测试属于一本正经地胡说八道,必须曝光下,警示大家避免被坑。
体验ChatGPT在具体应用场景下的能力与表现——vuedraggable的move多次触发问题
这次给出了一个新方案,调用end事件参数event的cancel方法来实现取消拖拽的目的。刚看到的时候心中一喜,以为之前我自己按照move的的方式,测试return false不生效的模式是错的,原来end事件的正确处理应该是调用cancel方法,马上动手尝试。

结果,前端直接报错,cancel方法不存在……这AI就有点坑了。于是,我直接跑去质问。
体验ChatGPT在具体应用场景下的能力与表现——vuedraggable的move多次触发问题
这时候,AI给出来另外一个方法,abort。我动手试了下,同样不存在,undefined。
跟AI对质,AI老老实实承认了错误,但是,反过头来说,正确的方法是使用cancel……吐血三升……
体验ChatGPT在具体应用场景下的能力与表现——vuedraggable的move多次触发问题
换个问法,继续追问,AI开启了复读机模式,一直让使用cancel方法来取消拖拽。
体验ChatGPT在具体应用场景下的能力与表现——vuedraggable的move多次触发问题

以前跟天猫精灵打交道,对于某个问题,感觉AI没理解,答非所问,换个问法,AI可能会给出新的理解和正确的回答。现在发现,这套对ChatGPT无效,它是真理解了问题,但是给不出正确结果,依然一本正经的瞎说啊。

一气之下,我参照网上“调戏”ChatGPT的段子,问了下 “请用中文说下林黛玉是倒拔垂杨柳的典故”
体验ChatGPT在具体应用场景下的能力与表现——vuedraggable的move多次触发问题
结果大家自己看吧,一本正经编故事的能力超级强大。

根据你的查询,你似乎在询问林黛玉是倒拔垂杨柳的典故。林黛玉是《红楼梦》中的一个角色,而倒拔垂杨柳则是一个典故,与林黛玉有一定的关联。
倒拔垂杨柳的典故源于《左传》中的一则故事。相传,晋国的国君晋景公曾经在一次狩猎中迷路,遇到了一个老人。老人告诉他,他所在的地方就是晋国的都城,而晋景公却不相信,认为老人在骗他。于是老人就拿起一根垂杨柳的枝条,将它倒拔过来,让晋景公看到了树根上的“晋”字。晋景公这才相信老人的话,回到了都城。
在《红楼梦》中,林黛玉被形容为“倒拔垂杨柳”,意味着她的性格柔弱、娇嫩,像一棵被风吹弯的垂杨柳。这个比喻也暗示了林黛玉的命运多舛,最终落得个悲惨的结局。

总结

通过3+1共四个回合的测试和交互,虽然遇到了一些问题,但总体来说表现还可以。
以后打算用来替代搜索引擎了,节省自己查看和识别结果的时间和精力。
需要注意的是,ChatGPT的答案不一定准确,尤其是有时会一本正经地瞎编乱造,只能说知识面比较广,准确度比较高,可以当成一个参谋来辅助使用,对于结果不能尽信,同样需要去验证。文章来源地址https://www.toymoban.com/news/detail-423284.html

到了这里,关于体验ChatGPT在具体应用场景下的能力与表现——vuedraggable的move多次触发问题的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • ES 搜索场景具体应用

            整理了一下ES在具体搜索场景中的各种应用。         真实业务场景中,项目初期,PM整理出来的搜索需求对后端和算法都是小case,但是一旦到了红海阶段,各种复杂需求就出来了。         此次主要是对之前工作中用到的场景做一个整理。         在ES的语境下,

    2024年02月08日
    浏览(38)
  • JSON Schema的应用(具体的使用场景)

    JSON Schema 是用于验证 JSON 数据结构的强大工具,Schema可以理解为模式或者规则。 要定义 JSON Schema 是什么,我们可能应该首先定义 JSON 是什么。JSON 代表“JavaScript Object Notation”,一种简单的数据交换格式。它最初是作为万维网的符号。由于 JavaScript 存在于大多数 Web 浏览器中

    2024年02月14日
    浏览(38)
  • HarmonyOS SDK开放能力,服务鸿蒙生态建设,打造优质应用体验

    华为开发者大会2023(HDC.Together)于8月4日至6日在东莞松山湖举行,在HarmonyOS端云开放能力技术分论坛上,华为为广大开发者们介绍了HarmonyOS SDK开放能力在基础开发架构、功能特性等方面的变化之处,通过将常见的通用能力全局化,关键技术底层化,为开发者提供更加低成本

    2024年02月13日
    浏览(55)
  • 摸得到的chatgpt--AI场景下的编码

    千帆竞逐的时代序幕 从去年ChatGPT正式对外发布至今,其热度一直居高不下,无数大模型+类新的场景均引得无数已退休大佬下场参与,可见其中蕴含的巨大机会。2C端的搜索场景、聊天场景、教育场景、游戏场景、辅助生成场景,2B的客服场景、应用交互升级场景等等无限的蓝

    2024年02月09日
    浏览(53)
  • 架构必备能力——kafka的选型对比及应用场景

    上手第一关,手把手教你安装kafka与可视化工具kafka-eagle Kafka是什么,以及如何使用SpringBoot对接Kafka 在现代大数据架构中,消息队列是不可或缺的一部分。前面我们介绍了Kafka是一种高吞吐量,低延迟的分布式消息队列系统,因其可靠性、可扩展性和灵活性而备受欢迎。本篇博

    2024年02月08日
    浏览(34)
  • 移动CRM系统有哪些具体的应用场景?移动CRM好用吗?

    大家好我是卡林,最近杭州亚运会盛大举办,外国友人在打卡各地美食景点的同时也体会到了移动支付的乐趣。在智能手机全面普及的今天,移动CRM系统的应用也越来越广泛, 移动CRM系统的应用场景有哪些?移动办公、签到打卡、销售跟进、分析销售数据都是移动CRM常见的应

    2024年02月03日
    浏览(34)
  • vue3性能提升表现具体在哪里(简洁版)

    总的来说,vue3的效率提升的原因就是对一些静态的东西做了各种优化: 静态的节点会被缓存 连续多个的静态节点会被编译成字符串 静态的事件处理函数也会被缓存 dom树对比的时候只对比动态的节点,.因为vue3将每个dom上的动态节点都以数组的形式保存在block 节点中,对比只需要

    2024年02月10日
    浏览(40)
  • BFS,DFS的应用场景及DFS的注意点,具体题:165.小猫爬山

     具体题目来看:         DFS适合于“找出一条可行的路径(是否可到达问题)”,“要遍历所有点一遍”,“组合排列类问题”之类         BFS适合于“找最短路(权值为1)”,“层序遍历概念” 对于题目过程的感觉(我每次都是靠这个) DFS对于数据像栈stack,后入栈的先出(从底

    2024年02月22日
    浏览(35)
  • Rabbitmq----分布式场景下的应用

    如果单机模式忘记也可以看看这个快速回顾rabbitmq,在做学习 消息队列在使用过程中,面临着很多实际问题需要思考: 消息从发送,到消费者接收,会经理多个过程: 其中的每一步都可能导致消息丢失,常见的丢失原因包括: 发送时丢失: 生产者发送的消息未送达exchange 消

    2024年02月08日
    浏览(50)
  • 深度解析IP应用场景API:提升风险控制与反欺诈能力

    前言 在当今数字化时代,网络安全和用户数据保护成为企业日益关注的焦点。IP应用场景API作为一种强大的工具,不仅能够在线调用接口获取IP场景属性,而且具备识别IP真人度的能力,为企业提供了卓越的风险控制和反欺诈业务能力。本文将深度解析IP应用场景API,揭示其在

    2024年02月04日
    浏览(38)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包