btea
btea
Currently, you can set `assetsinlinelimit` to 0 to make svg render normally. https://vite.dev/config/build-options.html#build-assetsinlinelimit
In the current scenario, the corresponding SVG id value after converting the vue file does not carry #, which fails to meet this condition. [example](https://play.vuejs.org/#eNq1kj9PwzAQxb+KdaxVUv5MVUBQ1AEGQMDoJUquiUtiG5+dRKry3bFdEhiqbrU8WO/3zvfO8h4etE46h7CCzGKrm9ziHZfMr4y6inUC+7Uabjks2ZJdhc2B9aK0tdculwZbDr8FscgRstrg1tP7NCdCSynVuUZK/H0XhTBFgxzSqUnq1XM2pG+XmyMNs3QeFxZgqVByK6pkR0r6t9gHM4dCtVo0aF61FUoShxWLJLC8aVT/HDVrHC4mvaix+Dqi72gIGoc3g4Sm85lmZnNToT3gzccLDv48w1aVLjzZCfiOpBoXMh5saydLH/ufL6Z9arUyVsjqkzaDRUnTUCFocI7Rz8F/iMcTo//FvU5uYh2XI4w/M0K5lQ==)
Maybe split `Provenance` into two columns? `CurrentProvenance` and `TargetProvenance`?
> no, I think one column is enough. But if it was downgraded, just print something like "danger, provenance removed" Whether this print information should be used when installing dependencies...
https://github.com/pnpm/pnpm/blob/95b088c7a7356d60ee05a68d1e07dcc2029494e3/network/fetch/src/fetchFromRegistry.ts#L9 To reduce the request content, a special request header is added, so the return content does not contain `_npmUser.trustedPublisher` related information.
What do you think of the current solution? Should the `provenance` column only be displayed when `trustPolicy` is set to `no-downgrade`, or should this column be displayed by default? @zkochan
要去除警告，应该给`全部`绑定一个`value`，目前`select`组件的选项都是通过`value`传值。
`value`现在其实既不支持设置`null`，也不支持设置`undefined`，默认值`undefiend`其实类似一个占位的作用。如果设置的`value`是`null`或者`undefined`，则会使用`label`来替代`value`值，同时会出现上述警告。 https://github.com/element-plus/element-plus/blob/0417037e0ea3999285929a2d0a0f41f47e2aef87/packages/components/radio/src/use-radio.ts#L21-L24 https://github.com/element-plus/element-plus/blob/0417037e0ea3999285929a2d0a0f41f47e2aef87/packages/components/radio/src/use-radio.ts#L50-L59 对于你上面提到的应用场景，我认为手动绑定一个值比较好，比如`全部`。（我一般在项目中这么做。） 如果你们确实需要`value`支持`null`和`undefined`，可以在后续版本中考虑支持。不过可能没那么快。
> @btea 但其实还是很有必要的，可能只有我自己这个场景比较常用。简单说一下我的场景： > > 其实这个就是个查询条件，全部就是没有条件，另外两个是有条件的。如果设置为 -1 值，那么在请求后端接口的时候就要再处理一次。 > 对，得前端自行处理过滤一下，我们一般这种情况不会传对应的参数给后端接口。 > 个人觉得这个东西支持 null 比较合理，因为原生就是支持null的，支持null并不会有什么错误，而且这种场景时用起来会非常方便。利大于弊。 这个如果支持的话估计还得额外加一些边界校验，比如有很多场景这些选项参数都是动态获取赋值，有可能赋值错误，存在多个选项值全为`undefined`或者`null`的情况。
Yes, this is a very limited modification unless there is extensive triggering logic. Feel free to turn it off, thanks for the review.