refactor: matching jsx component logic in string fragments #1861
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
| @@ -5,8 +5,7 @@ import type { IMdTransformerOptions } from '.'; | |||
|
|
|||
| let raw: typeof import('hast-util-raw').raw; | |||
| let visit: typeof import('unist-util-visit').visit; | |||
| const COMPONENT_NAME_REGEX = /<[A-Z][a-zA-Z\d]*/g; | |||
There was a problem hiding this comment.
这个改动删掉的逻辑会导致驼峰 props 的丢失，比如 <Foo relativePath="xxx"></Foo> 会被转成 <Foo relative-path="xxx"></Foo>
另外看了下关键改动点，应该就是正则的改动从匹配 <Foo 变成匹配 <Foo xxx>，虽然能解 issue 提到的 case 但仍然存在字符串属性值里的 JSX 被误伤的可能性，比如 <Foo str="<Bar xxx></Bar>" 应该还是会误伤，只要还是用正则而不是 AST 误伤就不可避免
建议还是按原逻辑替换，在最后一步遍历 properties 恢复 key 名的时候，多加一步恢复 value 的逻辑，整体流程是先误伤、再恢复，因为到恢复这一步的时候，hast-util-raw 已经通过 AST 解析把真正的标签处理过了，剩下的都是在 properties 里的字符串标签，正好是之前误伤的内容
There was a problem hiding this comment.
整体流程是先误伤、再恢复，因为到恢复这一步的时候，hast-util-raw 已经通过 AST 解析把真正的标签处理过了，
误伤后给 raw 处理得到的 properties 是有问题的。回复处理有点困难
我这边的解决思路还是用这个 pr， 然后继续跟进你说的 驼峰 props 丢失问题。先挂一下问题，对我来说有些挑战
There was a problem hiding this comment.
试了下 properties 的确已经乱了，我换了种思路解决，有空可以帮忙 review 下：#1872
|
Resolved #1872 |
🤔 这个变动的性质是？/ What is the nature of this change?
🔗 相关 Issue / Related Issue
fix #1836
💡 需求背景和解决方案 / Background or solution
解决方案
问了 chatGPT 然后得到一个匹配 jsx 组件的 正则表达式，试了一下能跑成功。然后写了一写测试用例。（不知道信不信得通）
📝 更新日志 / Changelog