V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  justdoit123  ›  全部回复第 3 页 / 共 9 页
回复总数  180
1  2  3  4  5  6  7  8  9  
214 天前
回复了 justdoit123 创建的主题 JavaScript JS 大数溢出问题
@jazzg62 请问下,如果这个数字要回传给后端你们怎么处理?也是让后端在 server 拿到后转成数字吗?
214 天前
回复了 justdoit123 创建的主题 JavaScript JS 大数溢出问题
@coala 同意。不过遗留项目,已成定局。
214 天前
回复了 justdoit123 创建的主题 JavaScript JS 大数溢出问题
@mxT52CRuqR6o5 可以呀。

问题是,不是所有的 bigint 转成 string 都能相安无事。

比如,如果这个数字是用来做 ID 之类的,那它是 string 也无所谓,因为很少会对 ID 做什么加减乘除的运算。

但是这个 bigint 可能是表示毫秒、表示钱,这时候转成 string 就很不方便。而且后端又不是只为 js 服务,还有 ios 跟 android 。
214 天前
回复了 justdoit123 创建的主题 JavaScript JS 大数溢出问题
转成 string 给前端,前端送回给后端的时候,后端得再转回 int ( python 后端),现在其实就是这么做的。就是时不时会遗漏掉,而且这种问题是要等溢出你才会发现。基于此,想寻找一个更好的方案。
214 天前
回复了 justdoit123 创建的主题 JavaScript JS 大数溢出问题
@realJamespond 就是不想再在后端转字符串了呀!

除非从 DB Access 层就把所有 bigint 都转成 string ,顺便好奇问下大家也是这么做的吗?像 timestamp 这种,在 db 里用 bigint 存储,但是使用的时候是实实在在要当数字使用的,如果转成 string 用的时候还要转回去。
218 天前
回复了 justdoit123 创建的主题 Vim VIM & Python
@z1645444 感谢,这个多少能满足了我的需求。Pycharm 貌似没有专门 extend selection 到整个函数或者 class 的接口,不知道是不是我搜索得不对,不过直接用 extend selection 也够用。
219 天前
回复了 justdoit123 创建的主题 Vim VIM & Python
我用的不是纯 vim ,主要在 pycharm 里使用。纯 vim 偶尔在 server 的 cli 里使用。这些 plugin 貌似用不了。
219 天前
回复了 dnjat 创建的主题 程序员 前后端 页面 url 与 api url 如何统一命名风格.
@javaisthebest 哈哈~~ 太真实。 让我想起了 DELETE /user/session/123123123 。 说到底,rest 还是不适合复杂情景。
223 天前
回复了 softlight 创建的主题 程序员 复盘一个独立开发 2 年的项目
感谢分享。

我感觉独立开发者,做这种项目,更多的是打磨给别人写外包的脚手架。面向的用户是开发者自己就行了,什么拖拽编辑等等需求都不太强烈。
224 天前
回复了 NoKey 创建的主题 程序员 没有 https 的情况下, jwt 是不是也不安全?
https 保证通讯安全。jwt 只是保证认证的格式,你用自己生成的随机数都可以,只不过它带有一些基础信息,可以省去向中心服务验证的过程。

客户端拿到 token 后,要自己存在一个安全的地方。
- 像浏览器场景,基本都要存在 http-only 的 cookie 里。这个 http-only 表示只有浏览器能读取,js 无法读取。跟 http/https 没关系。这样能保证攻击注入的 js 无法读出你的 token 。
- app 场景,应该是直接存 app 本地就好,别的 app 读取不到,没写过 app 不知道这方面的安全规范。
- server 2 server 场景,你拿到 token 后就自己存好,方式各种各样。大部分情况下,因为这个 server 只有你能访问,所以直接明文“随意”存个位置也是可以的。

你辛辛苦苦把 token 保存得很好,但是对外传输的时候竟然用了明文的 http ,那别人就特别容易截到你的 token ,来伪造你的请求。比如,把你网上银行的钱转走。。。
224 天前
回复了 justdoit123 创建的主题 前端开发 C 端的 Button 组件要怎么封装?
@NerbraskaGuy antd 那种适用于后台系统我知道。toC 场景下,这种“样式没法复用很正常”真的是常态吗? T_T
来来来,细说 3 倍效率怎么计算出来的!为什么是 3 而不是 100 ?写 100 会不会更吸引人?
分不清 token 、session 、cookie 这三者关系的,大有人在。其实很正常,不做 web 自然没太大必要了解 session 与 cookie 的关系,安全性 严肃性不高的场景,随便一把梭也是能用的。
贴个经常要处理的 python 问题。

TypeError: unsupported operand type(s) for -: 'int' and 'NoneType'

不是针对 python ,只是刚好又要修个这种 bug 。js 也是一样,经常有 undefined 问题。

写代码的时候,脑袋里还要记忆某个属性存在不存在是真 tm 的累。然后,这种 NoneType Error 、undefined 问题还是数据相关的,可能你开发的时候压根不会碰到。
@ChrisFreeMan 我认为底层库的最低要求是,声明好接口的参数与返回值类型,保证用的人能清晰的知道怎么调用即可。至于实现部分,如果掌握不住体操,那就 any 吧。
还有,凡事多先自己体会下,技术圈有点娱乐化了,尤其是前端。这种现象感觉也开始蔓延到后端。天天要用新技术重写一个世界。最近感觉吐槽 Go 的文章开始多起来了,然后开始吹 Rust 。估计再过个一两年,今天的小甜甜,也要变成牛夫人。

你管他大佬不大佬,大佬还能帮你写 CRUD ,还能帮你写基础建设吗?大佬,也会犯错误。
写写小脚本、小应用,倾向于不用。

但是,项目一大,你怎么知道 item 、data 、form 等等这些对象有什么属性?靠 JS + VSCode 是不靠谱的,补全不精准,重命名也是个大硬伤,动不动把很古老的文件里的同名属性也给我改了,这怎么能忍?

经常看到有人吐槽 AnyScript 。说到底要嘛学得不深,要嘛由钻研得太深。该用 any 、as 、!的时候,你就大胆的使用。然后尽量不要类型转换超过 3 次,这种类型体操做起来累,看起来也是很累! TS 已经是可以渐进式的使用了,别一上来自缚手脚,搞个火箭发射台。
1  2  3  4  5  6  7  8  9  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   856 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 26ms · UTC 22:00 · PVG 06:00 · LAX 15:00 · JFK 18:00
Developed with CodeLauncher
♥ Do have faith in what you're doing.