首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

js 只能点赞一次

在JavaScript中实现“只能点赞一次”的功能,通常涉及到前端与后端的交互。以下是相关的基础概念、优势、类型、应用场景以及解决方案:

基础概念

  1. 前端验证:使用JavaScript在客户端进行初步验证。
  2. 后端验证:在服务器端进行严格的验证,确保数据的一致性和安全性。
  3. 状态管理:通过前端的状态管理(如React的state或Vue的data)来控制点赞按钮的状态。

优势

  • 用户体验:实时反馈用户操作,提升用户体验。
  • 数据安全:前后端双重验证,防止恶意刷赞。

类型

  1. 前端控制:仅在前端进行点赞次数的控制。
  2. 后端控制:仅在后端进行点赞次数的控制。
  3. 前后端结合:前端和后端共同控制点赞次数。

应用场景

  • 社交媒体:用户对帖子、评论等进行点赞。
  • 电商平台:用户对商品进行点赞。

解决方案

前端实现

代码语言:txt
复制
// 假设有一个点赞按钮
const likeButton = document.getElementById('like-button');
let hasLiked = false;

likeButton.addEventListener('click', async () => {
    if (hasLiked) {
        alert('你已经点过赞了!');
        return;
    }

    // 发送点赞请求到后端
    try {
        const response = await fetch('/api/like', {
            method: 'POST',
            headers: {
                'Content-Type': 'application/json'
            },
            body: JSON.stringify({ postId: '123' }) // 假设postId是你要点赞的帖子ID
        });

        if (response.ok) {
            hasLiked = true;
            likeButton.disabled = true; // 禁用按钮
            likeButton.innerText = '已点赞';
        } else {
            alert('点赞失败,请重试');
        }
    } catch (error) {
        console.error('Error:', error);
        alert('点赞失败,请重试');
    }
});

后端实现(Node.js示例)

代码语言:txt
复制
const express = require('express');
const app = express();
app.use(express.json());

const likes = {}; // 存储点赞状态

app.post('/api/like', (req, res) => {
    const { postId } = req.body;

    if (!postId) {
        return res.status(400).json({ message: '缺少postId' });
    }

    if (likes[postId]) {
        return res.status(400).json({ message: '你已经点过赞了' });
    }

    likes[postId] = true;
    res.status(200).json({ message: '点赞成功' });
});

app.listen(3000, () => {
    console.log('Server is running on port 3000');
});

解释

  1. 前端部分
    • 使用hasLiked变量来记录用户是否已经点赞。
    • 当用户点击点赞按钮时,首先检查hasLiked状态。
    • 如果未点赞,则发送点赞请求到后端,并更新按钮状态。
  • 后端部分
    • 使用一个简单的对象likes来存储每个帖子的点赞状态。
    • 当收到点赞请求时,检查该帖子是否已经被点赞。
    • 如果未点赞,则更新点赞状态并返回成功响应;否则返回错误响应。

注意事项

  • 数据持久化:在实际应用中,点赞状态应存储在数据库中,而不是内存中。
  • 并发处理:在高并发场景下,需要考虑并发请求的处理,确保数据的一致性。
  • 安全性:防止恶意用户通过篡改前端代码绕过点赞限制,后端验证是必不可少的。

通过前后端结合的方式,可以有效实现“只能点赞一次”的功能,提升用户体验和数据安全性。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

  • Redis实现点赞取消点赞

    至于多久从 Redis 取一次数据存到数据库中,根据项目的实际情况定吧,我是暂时设了两个小时。 项目需求需要查看都谁点赞了,所以要存储每个点赞的点赞人、被点赞人,不能简单的做计数。...由于需要记录点赞人和被点赞人,还有点赞状态(点赞、取消点赞),还要固定时间间隔取出 Redis 中所有点赞数据,分析了下 Redis 数据格式中 Hash 最合适。...因为 Hash 里的数据都是存在一个键里,可以通过这个键很方便的把所有的点赞数据都取出。这个键里面的数据还可以存成键值对的形式,方便存入点赞人、被点赞人和点赞状态。...设点赞人的 id 为 likedPostId,被点赞人的 id 为 likedUserId ,点赞时状态为 1,取消点赞状态为 0。...id,点赞用户id,点赞状态。

    3.1K31

    Linus看了都点赞的一次Bug Fix

    TencentOS 内核团队的 Patch 被公认为最佳修复, Linus Torvalds 更评价其"不明觉赞,祝顺利" 。本文将由浅入深解析底层原理,厘清问题来龙去脉。...这并不是我们第一次解决内核中的隐藏问题或疑难问题。...新的插入逻辑确实更绕一点,不过在乐观情况下(实际测试中乐观情况占比几乎是绝对性的压倒的,即便是高压力的并发场景),若不涉及 split,只需要步骤 2 这里进行一次走树即可,这基本上已经是理论上的最佳方式...因为缺乏 reproducer,同时没有有效的 debug 信息,社区很大程度上也只能盲猜。就像开头我们已经介绍过的,这一问题让社区的几位 Maintainer 都颇为困惑。...不过由于我们的优化和 Fix Patch 已经在几个月前就合入了,上游开发并未受阻,Fix 也很快就回合到 LTS,最终为这一问题画上了句号,并顺带让更多运行 Linux 的设备,都能快那么一点点。

    20620

    Redis是如何实现点赞、取消点赞的?

    至于多久从 Redis 取一次数据存到数据库中,根据项目的实际情况定吧,我是暂时设了两个小时。 项目需求需要查看都谁点赞了,所以要存储每个点赞的点赞人、被点赞人,不能简单的做计数。...1.4 点赞数据在 Redis 中的存储格式 用 Redis 存储两种数据,一种是记录点赞人、被点赞人、点赞状态的数据,另一种是每个用户被点赞了多少次,做个简单的计数。...由于需要记录点赞人和被点赞人,还有点赞状态(点赞、取消点赞),还要固定时间间隔取出 Redis 中所有点赞数据,分析了下 Redis 数据格式中 Hash 最合适。...设点赞人的 id 为 likedPostId,被点赞人的 id 为 likedUserId ,点赞时状态为 1,取消点赞状态为 0。...id,点赞用户id,点赞状态。

    3.3K50

    Redis是如何实现点赞、取消点赞的?

    至于多久从 Redis 取一次数据存到数据库中,根据项目的实际情况定吧,我是暂时设了两个小时。 项目需求需要查看都谁点赞了,所以要存储每个点赞的点赞人、被点赞人,不能简单的做计数。...由于需要记录点赞人和被点赞人,还有点赞状态(点赞、取消点赞),还要固定时间间隔取出 Redis 中所有点赞数据,分析了下 Redis 数据格式中 Hash 最合适。...设点赞人的 id 为 likedPostId,被点赞人的 id 为 likedUserId ,点赞时状态为 1,取消点赞状态为 0。...id,点赞用户id,点赞状态。...不然有可能出现距离上一次同步1小时59分的时候服务器更新 , 把整整两小时的点赞数据都给清空了 . 如果点赞设计到比较重要活动业务的话这就很尴尬了 .

    2.5K20

    Redis 是如何实现点赞、取消点赞的?

    至于多久从 Redis 取一次数据存到数据库中,根据项目的实际情况定吧,我是暂时设了两个小时。 项目需求需要查看都谁点赞了,所以要存储每个点赞的点赞人、被点赞人,不能简单的做计数。...1.4 点赞数据在 Redis 中的存储格式 用 Redis 存储两种数据,一种是记录点赞人、被点赞人、点赞状态的数据,另一种是每个用户被点赞了多少次,做个简单的计数。...由于需要记录点赞人和被点赞人,还有点赞状态(点赞、取消点赞),还要固定时间间隔取出 Redis 中所有点赞数据,分析了下 Redis 数据格式中 Hash 最合适。...id,点赞用户 id,点赞状态。...不然有可能出现距离上一次同步 1 小时 59 分的时候服务器更新 , 把整整两小时的点赞数据都给清空了 . 如果点赞设计到比较重要活动业务的话这就很尴尬了 . (完)

    7K64

    Redis是如何实现点赞、取消点赞的?

    至于多久从 Redis 取一次数据存到数据库中,根据项目的实际情况定吧,我是暂时设了两个小时。 项目需求需要查看都谁点赞了,所以要存储每个点赞的点赞人、被点赞人,不能简单的做计数。...1.4 点赞数据在 Redis 中的存储格式 用 Redis 存储两种数据,一种是记录点赞人、被点赞人、点赞状态的数据,另一种是每个用户被点赞了多少次,做个简单的计数。...由于需要记录点赞人和被点赞人,还有点赞状态(点赞、取消点赞),还要固定时间间隔取出 Redis 中所有点赞数据,分析了下 Redis 数据格式中 Hash 最合适。...设点赞人的 id 为 likedPostId,被点赞人的 id 为 likedUserId ,点赞时状态为 1,取消点赞状态为 0。...id,点赞用户id,点赞状态。

    2.6K20

    Redis 是如何实现点赞、取消点赞的?

    至于多久从 Redis 取一次数据存到数据库中,根据项目的实际情况定吧,我是暂时设了两个小时。 项目需求需要查看都谁点赞了,所以要存储每个点赞的点赞人、被点赞人,不能简单的做计数。...1.4 点赞数据在 Redis 中的存储格式 用 Redis 存储两种数据,一种是记录点赞人、被点赞人、点赞状态的数据,另一种是每个用户被点赞了多少次,做个简单的计数。...由于需要记录点赞人和被点赞人,还有点赞状态(点赞、取消点赞),还要固定时间间隔取出 Redis 中所有点赞数据,分析了下 Redis 数据格式中 Hash 最合适。...id,点赞用户 id,点赞状态。...不然有可能出现距离上一次同步 1 小时 59 分的时候服务器更新 , 把整整两小时的点赞数据都给清空了 . 如果点赞设计到比较重要活动业务的话这就很尴尬了 .

    2.9K10

    使用 Redis 如何实现点赞,取消点赞呢?

    至于多久从 Redis 取一次数据存到数据库中,根据项目的实际情况定吧,我是暂时设了两个小时。 项目需求需要查看都谁点赞了,所以要存储每个点赞的点赞人、被点赞人,不能简单的做计数。...1.4 点赞数据在 Redis 中的存储格式 用 Redis 存储两种数据,一种是记录点赞人、被点赞人、点赞状态的数据,另一种是每个用户被点赞了多少次,做个简单的计数。...由于需要记录点赞人和被点赞人,还有点赞状态(点赞、取消点赞),还要固定时间间隔取出 Redis 中所有点赞数据,分析了下 Redis 数据格式中 Hash 最合适。...设点赞人的 id 为 likedPostId,被点赞人的 id 为 likedUserId ,点赞时状态为 1,取消点赞状态为 0。...id,点赞用户id,点赞状态。

    2.3K20

    Auto.js实现视频号点赞自动化

    给大家分享一个自动化点赞视频号的功能,仅供大家学习参考,请勿滥用! 基本实现思路: 1. 找到点赞图标和点赞数量的父容器A; 2. 通过父容器A找到点赞图标的可点击对象B; 3....点击可点击对象B进行点赞; 正常来说,上面的操作已经完成了我们想要的功能,但是可能会因为人为的滑屏,将已经点赞了再次点击,变为了取消赞,所以要做下面的操作: 5....再次通过父容器A找到点赞数量D; 6. 比较点赞前的点赞数量C与点赞后的点赞数量D,如果数量C大于数量D说明之前取消了点赞,再次点击可点击对象B补回点赞; 7....().findOne(id("com.tencent.mm:id/fnp")); // 点赞前文字 let num1 = goodNum1.text() - 0; // 开始来点赞...// 补回点赞 obj.click(); sleep(1000); }; }; while(true){ // 开始点赞 goodClick(

    1.6K10

    HarmonyOS实战—实现抖音点赞和取消点赞效果

    双击点赞 和 双击取消点赞 如:在抖音中双击屏幕之后就可以点赞,小红心就会变亮 [在这里插入图片描述] 把白色和红色的心形图片复制到 media 下 [在这里插入图片描述] [在这里插入图片描述] 需要图片的可以自取...业务分析: 双击屏幕之后点赞。(上面已实现),再次双击屏幕之后,不会取消点赞,只有点击后红心之后才能取消点赞。...单击红心也可以点赞,再次单击红心就会取消点赞 实现思路: 给最外层的布局添加双击事件,双击之后点赞,变成红色心。 如果已经被点赞,那么还是修改为红色心,相当于不做任何处理。 给图片添加单击事件。...如果没有点赞,单击之后,白色心变成红色心。 如果已经点赞了,单击之后,红色心变成白色心。...,只有点击小红心才能取消点赞 [在这里插入图片描述]

    2K20

    有赞埋点实践

    但如果业务线、终端众多,数据需求多样,就需要设计好埋点模型和采集规范,工具化、平台化、流程化的管理来保证埋点的质量。 二、事件模型 首次需要思考的是,如何描述和记录用户的一次行为。...我们设计了可以承载以上信息的日志模型,并保持必要的可扩展性,将数据映射到schema的各个字段中,一次行为便完整的记录下来。...代码埋点的优势有: 事件标识明确 业务参数丰富 事件的触发方式可以灵活自定义 分析更方便、精确 随之而来的是以下问题: 前端代码的开发、管理成本 只能收集到事件上线之后的数据 在业务需求复杂,无痕埋点收集到的信息无法支持分析时...四、埋点sdk 为简化前端同学的埋点开发工作,使其只需要关注于业务本身,并对埋点的一些约定进行必要的约束,有赞开发了多个端(js/小程序/android/ios/java)的埋点sdk。...七、埋点管理平台 有赞的早期阶段,所有业务的埋点方案都是记录在wiki中。

    2.6K21

    你还敢乱点赞吗?

    点赞真的是成本低、效率高的社交好方法吗? ? 疑惑 你在社交媒体(例如微信、QQ和微博等)上点过赞没有? 一定点过吧?有的人一天还要点很多次赞呢。 问题是你在什么情况下点赞?...面对你的点赞,要么人家不打算理你,要么想理你也没有合适的办法。于是只能不理你。 误会 刚才还只是说点赞这个行为在社交中收益不高而已,下面我们来谈谈潜在损失吧。 点赞究竟代表什么意思?你真说得清楚吗?...从信息论上说,点赞动作只有1个比特,它只能表示2种状态——0或者1。 你不点赞没人会追究你。毕竟这是个注意力稀缺年代,你大可以说当时没看见对方发的朋友圈。可是你点了赞,那就只剩下“1”了。...一个赞怎么可能同时代表喜悦、悲伤、忧愁、同情、惊恐、赞同……这么多的情感呢? 所以,你随便点赞太多,造成误会将是大概率事件。 我有个朋友,人缘很好。有一次早晨牙疼到医院去看病。...讨论 看到这里,你还敢随便点赞吗?你觉得什么情况下最适合点赞?欢迎留言,我们一起讨论。 ----

    90620
    领券