映射的Protobuf结构是该值是对象数组的位置？
我希望在Protobuf中编码这样的地图：
const newVisMap = new Map<number, IOutput[]>();
该值是一个具有相同接口的对象数组（带有一个可选条目）：
interface IOutput {
glyph: string,
color: string,
hex?: string,
order: number
}
我的问题是我将如何将此地图编码为Protobuf中的字段信息。还是我应该将地图转换为另一种格式？这是使用Protobuf.js NPM模块。
I am looking to encode a map like this in a protobuf:
const newVisMap = new Map<number, IOutput[]>();
The value is an array of objects that all have the same interface (with one optional entry):
interface IOutput {
glyph: string,
color: string,
hex?: string,
order: number
}
My question is how I would go about encoding this map as a field in a protobuf message. Or should I convert the map to another format? This is using the protobuf.js npm module.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这个问题中缺少很多细节，但我认为我可以推断出，尽管这些物体都共享相同的界面，但它们实际上是不同类型的，glyph and hex（是字符串）表明这就是在这里之间的差异对象是。
这里的问题是GPB涉及强大的类型。如果编写架构时，最终是数据的完整定义，这是最有用的。字符串暗示将以某种方式解析的字符串提示，并且该模式并没有告诉我们如何完全解释数据。
例如，您的颜色为字符串；这可能是三个整数，一个是红色，绿色，蓝色的。颜色名称模棱两可！还是从颜色的X HEX字符串？
同样，如果字形中的信息不足以构建对象（也许是指类标识，并且类构造函数知道创建新对象所需的参数），那么您就可以分开信息。代码中有些，有些在模式中。这可能对自己来说是完全可以的，但是如果其他用不同语言编写的其他系统收到此数据，可能会出现问题。收件人不会有您的构造函数！
这样做的最好方法是将GPB消息完全描述每个可能的对象，然后将它们包含在总体
Oneof消息中（这是您发送的内容）。这样，您要传达对象类型，并明确（并且难以误解）有关对象的数据。如果它们在内容和行为上都非常相似和通用，那么您可能会有一个可以描述所有不同对象的通用类，在这种情况下，只需描述该类。
考虑到有关串行地图并发送该评论的评论的导入很有趣。串联是序列化，而GPB是另一个序列化。意义在于，您需要进一步使用GPB模式（如上所述），或者根本不使用它！
There's a lot of detail missing from the question, but I think I can infer that, although the objects all share the same interface, they are in fact of different types where glyph and hex (being strings) suggest that this is where the differences between objects are.
The problem here is that GPB is all about strong types; it's most useful if, when writing a schema, it ends up being the complete definition of the data. The use of string hints that that is going to get parsed in some way, and that the schema isn't telling us how to completely interpret the data.
For example, you have color as string; that could be better as three integers, one for red, green, blue. A color name is ambiguous! Or is it a X hex string from a color?
Also if the information in glyph is not enough to be able to construct an object (perhaps it's referring to class identity, and it is the class constructor knows the parameters needed to create a new object), then you have a separation of information; some in the code, and some in the schema. That might be perfectly OK for yourself, but it might be problematic if this data is ever received by some other system written in a different language; the recipient won't have your constructors!
The best way of doing this would be to have GPB messages in a schema that fully describe each possible object, and then have them contained in an overall
oneofmessage (which is what you send). That way you're conveying object type, and explicit (and hard to misinterpret) data about the object.If they're all very similar and generic in content and behaviour, you might be OK having a universal class that can describe all your different object, in which case just describe that class.
It's interesting to consider the import of your comment about stringifying the map and sending that. Stringifying is serilisation, and GPB is another serialisation. The significance is that either you need to go further with your GPB schema (as I suggest above), or not use it at all!