未加星标

Making functions unsafe_

字体大小 | |
[前端(javascript) 所属分类 前端(javascript) | 发布者 店小二05 | 时间 2019 | 作者 红领巾 ] 0人收藏点击收藏

In a codebase that has a mix of Typescript/Flow and javascript, functions get used across these boundaries, usually. When that’s done without care, it might end up introducing subtle bugs that may not be caught during compile time. For instance:

// buildRenderData.ts export function countCells (input: { cells: Array<Array<object>> }) { } // menu.jsx import { countCells } from './buildRenderData.ts'; const something = { thats: 'undefined' // } countCells(something.thats.undefined); // fail!

In this pseudo-real-world example, the countCells function was used only in the file where it was defined, so all the necessary compile-time guards were provided using TypeScript. Intentionally, to avoid unnecessary checking for argument shape (because why do something that’s provided by the tooling, right?) no explicit checks were added to countCells function.

Later in the implementation, I had to reuse the function inside the component file that was originally written in JavaScript. If I don’t check for the validity of the input at the location it’s getting used, that function might break at runtime and crash the program. Now, since I wrote both the pieces in the code, I know that I have to add this check. But what about more complex functions that take complex arguments, but are inherently reusable? You won’t want to sprinkle type-checking code for every function that’s exported, because that’s almost repeating what TypeScript is doing for you, and worse, the code you write does the checking during runtime which may get costly. How do you, as an author of a function, hint others that a function is inherently “unsafe”?

This is something I’m stealing from React land. When deprecation a function in React, the team generally marks that function with a UNSAFE_ prefix. So you, as a library user, know that this feature is going to get removed in the future. You may use it today, but marking it as such makes the decision to use it an explicit opt-in.

So I’m starting to write the small, reusable functions that don’t have any explicit checks like so:

// buildRenderData.ts // unsafe_ prefix denotes that this function doesn’t do any explicit // input validity. export function unsafe_countCells (input: { cells: Array<Array<object>> }) { } // menu.jsx import { unsafe_countCells as countCells } from './buildRenderData.ts'; const something = { thats: 'undefined' // } // still fails, but at least now it’s YOUR fault. ( ) countCells(something.thats.undefined);

I think this’ll work nicely :)

本文前端(javascript)相关术语:javascript是什么意思 javascript下载 javascript权威指南 javascript基础教程 javascript 正则表达式 javascript设计模式 javascript高级程序设计 精通javascript javascript教程

代码区博客精选文章
分页:12
转载请注明
本文标题:Making functions unsafe_
本站链接:https://www.codesec.net/view/628401.html


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 前端(javascript) | 评论(0) | 阅读(69)