Forwarded from Jack Works
Arki 的每日 BUG 观察
Photo
首先众所周知 setTimeout 是平台的 API，可以直接判断平台 API 在所有 promise 后面走 event loop（不过现在有个例外 queueMicrotask，平台 API 但是不是 event loop，这个倒是可以搞到 JS 规范里）。
然后我对代码执行的建模是这样的：
Promise Reaction Job 队列（微任务队列）里面存了已经解决的 Promise 的 Reaction（then/catch/finally）
开始执行代码时，（初次运行时）先执行所有同步的代码，
然后按顺序执行所有的 Promise Reaction Job 里的 Reaction。
执行代码时新解决的 Promise 上面挂的 Reaction 就会推到队列里。
全部执行完毕之后 idle，等待 event loop 中的事件触发下一次执行代码。
对于上面的代码，我的理解过程是这样的（不提 setTimeout 因为肯定是最后一个）：
line 5:首先同步执行 promise 的构造器，log-promise
然后直接解决了 promise（也就是说接下来附加到这个 promise 的 reaction 会直接进队列），目前队列是空的，因为 promise 没有 reaction。
line 10: async iife 和 new Promise 没什么区别，所以 log async start。
line 12: await promise 了（参考规范 27.7.5.3），首先判断是不是平凡的 Promise，如果不是还得包一层（step 2）。
生成两个 reaction，一个是被 await 的 promise resolve 了之后执行的代码，一个是 reject 之后（step 3 和 5）。
然后规范 step 7 直接执行了 promise.then(第一个 reaction，第二个reaction），然后暂停了当前 async function 的执行。
因为 promise 已经解决了，所以把第一个 reaction 排进队列（队列里的第一个 reaction）
line 16: 再给 promise 挂一个 resolve reaction。同理，进队列，排在上面那个的后面
line 20: log-end
此时同步代码已经执行完了，接下来按顺序执行队列打出 promise resolve 和 log-promise1-then。
假如在 line 13 前面加 promise.then(() => ...)，那它按队列，排在 log-promise1-then 后面。
然后我对代码执行的建模是这样的：
Promise Reaction Job 队列（微任务队列）里面存了已经解决的 Promise 的 Reaction（then/catch/finally）
开始执行代码时，（初次运行时）先执行所有同步的代码，
然后按顺序执行所有的 Promise Reaction Job 里的 Reaction。
执行代码时新解决的 Promise 上面挂的 Reaction 就会推到队列里。
全部执行完毕之后 idle，等待 event loop 中的事件触发下一次执行代码。
对于上面的代码，我的理解过程是这样的（不提 setTimeout 因为肯定是最后一个）：
line 5:首先同步执行 promise 的构造器，log-promise
然后直接解决了 promise（也就是说接下来附加到这个 promise 的 reaction 会直接进队列），目前队列是空的，因为 promise 没有 reaction。
line 10: async iife 和 new Promise 没什么区别，所以 log async start。
line 12: await promise 了（参考规范 27.7.5.3），首先判断是不是平凡的 Promise，如果不是还得包一层（step 2）。
生成两个 reaction，一个是被 await 的 promise resolve 了之后执行的代码，一个是 reject 之后（step 3 和 5）。
然后规范 step 7 直接执行了 promise.then(第一个 reaction，第二个reaction），然后暂停了当前 async function 的执行。
因为 promise 已经解决了，所以把第一个 reaction 排进队列（队列里的第一个 reaction）
line 16: 再给 promise 挂一个 resolve reaction。同理，进队列，排在上面那个的后面
line 20: log-end
此时同步代码已经执行完了，接下来按顺序执行队列打出 promise resolve 和 log-promise1-then。
假如在 line 13 前面加 promise.then(() => ...)，那它按队列，排在 log-promise1-then 后面。
Forwarded from Manjusaka 的碎碎念（以及摇曳露营 S4 2027 放送予定）
lucia-auth 作者写了一本小册，https://thecopenhagenbook.com
介绍了常见的 Auth 的一些实现，质量非常高。强烈推荐
介绍了常见的 Auth 的一些实现，质量非常高。强烈推荐
Forwarded from Yu’s Life (Yu’s Life)
📖 How the Raycast API and extensions work #article
备注：raycast 的体验真的甩同类 Alfred 已经太远了，解读技术实现的文章也很清晰
https://www.raycast.com/blog/how-raycast-api-extensions-work
备注：raycast 的体验真的甩同类 Alfred 已经太远了，解读技术实现的文章也很清晰
https://www.raycast.com/blog/how-raycast-api-extensions-work
Raycast
How the Raycast API and extensions work - Raycast Blog
Learn more about how we built the Raycast API and how it works under the hood
Forwarded from cosine - 前端人の日常频道
#优质博文 #前端 #权限控制 #全栈
好文。
Choosing the best access control model for your frontend
author Temitope Oyedele
好文。
Choosing the best access control model for your frontend
AI 摘要：本文探讨了前端应用中最佳访问控制模型的选择，重点分析了 RBAC（基于角色的访问控制）、ABAC（基于属性的访问控制）、ACL（访问控制列表）和 PBAC（基于策略的访问控制）的优缺点。作者指出，虽然不同模型各有适用场景，但 RBAC 因其简单性、可扩展性和与前端框架（如 React/Next.js）的良好兼容性，成为大多数前端应用的首选方案。文章还通过 Next.js 示例演示了 RBAC 的具体实现，并讨论了混合模型的潜在应用场景。
1. 访问控制的核心作用
• 前端访问控制的核心目标是优化用户体验（而非安全 enforcement），通过动态显示可交互的 UI 元素减少用户困惑。
2. 主流访问控制模型对比
• RBAC（基于角色的访问控制 role-based）
• 通过用户角色分配权限，适合大多数前端应用
• 优势：易于维护、性能良好、与前端框架集成度高
• 局限：缺乏细粒度控制（如无法处理动态条件）
• ABAC（基于属性的访问控制 attributes-based）
• 根据用户/环境属性动态决策
• 适用场景：需要实时权限变更的复杂系统
• 前端缺陷：性能开销大、状态管理复杂
• 简单解释一下，这就像说，“如果用户的部门是 X，文档是 Y 分类的，并且是在工作时间，那么允许访问。
• ACL（访问控制列表 access control list）
• 用于在单个资源级别定义权限。这意味着访问权限直接分配给特定用户或组
• 前端痛点：权限列表扫描导致性能下降，难以扩展
• PBAC（基于策略的访问控制 policy-based）
• 依赖中央策略引擎（如 OPA）动态评估规则
• 建议仅限后端使用，前端实现会导致界面延迟和闪烁
• 它在后端服务中大放异彩，尤其是在微服务架构中，您希望跨 API 实现集中、一致的策略实施。
3. RBAC 的 Next.js 实现示例
• 演示项目结构：角色配置（roles.js）、自定义钩子（useRBAC）、动态仪表盘（Dashboard.js）
• 关键功能：
• 基于角色的 UI 元素显隐控制
• 受保护路由（如 /admin）的权限验证
• 无权限用户的 403 重定向
4. 混合模型的应用
• RBAC + ABAC：角色基础规则 + 属性动态补充（如部门限定访问）
• RBAC + ACL：角色为主，ACL 处理特殊例外（需谨慎使用）
• PBAC 应严格限于后端 API 层
5. 结论与建议
• 前端访问控制的本质是用户体验优化
• RBAC 是大多数场景的最佳平衡选择
• 复杂场景可谨慎组合模型（如 RBAC+ABAC）
• 强调：前端控制需与后端安全验证配合
author Temitope Oyedele
LogRocket Blog
Choosing the best access control model for your frontend - LogRocket Blog
This article explores how each access control model works, their frontend suitability, and why RBAC might be the best choice.
Forwarded from QC 的小树林
https://alic.dev/blog/fast-lexing 太熟悉了，基本上全是以前频道发过的技巧。phf、pext 就不提了，logos 的 stacking lookup table 我们有用在 paguroidea 里，那个 simd 查表的做法则是来自 simd-json
alic.dev
Beating the fastest lexer generator in Rust
This blog post takes a look at a popular Rust crate for generating lexers, and my attempt to outperform it.
Forwarded from cos
https://css-tip.com/explore/alignment/ 这篇讲 CSS 对齐讲的好明白ww感觉之前看 align-items 和 justify-content 都朦朦胧胧的，还得一起讲最好。
Css-Tip
The Fundamentals of CSS Alignment
This deep dive covers everything you need to know about CSS alignment. It's time to stop doing trial and error and finally understand how everything works!
Forwarded from 蜜柑不时抱
mcyoung.xyz
Why SSA? · mcyoung
Forwarded from Reorx’s Forge