Questions on the generated code ? about protobuf-ts HOT 3 CLOSED

Oh I guess it's because non-const enum would not be replaced by a value and consumes more bytes.

Exactly.

Replacing "kind" string literals:

I was about to replace the union type "scalar" | "map" | "enum" | "message" with an enum - then I was made aware of the const enum problem and I left it as is.

I think the most consistent improvement would be to actually use an enum:

export enum FieldKind {
  SCALAR, MAP, ENUM, MESSAGE
}

The generated field information could use the same pseudo-inlined code:

kind: 1 /*FieldKind.SCALAR*/

This would save quite some bytes in the generated code. It would add some bytes to the runtime, because string literals "scalar" would need to be replaced with FieldKind.SCALAR. But maybe there are some ways around it.

Maybe an other idea would be to create locale (i.e. not exported) const enum in this file - I am not sure if this would work with react though ?

Not sure either. But this could be a good general approach that could be used internally within the runtime (there are many references to the non-const ScalarType and many references to the field kind union type).

An other possible optimization could be to skip the no if equal to the index (+1) in the table, i.e.

Good point. Not sure if worth it though, because it is quite convenient to be able to lookup a field by number in the code.

from protobuf-ts.

Thanks for the detailed answer.

An other possible optimization could be to skip the no if equal to the index (+1) in the table, i.e.

Good point. Not sure if worth it though, because it is quite convenient to be able to lookup a field by number in the code.

The idea here is that the runtime would add the no property when no present (by inferring the value from the index).

from protobuf-ts.

The idea here is that the runtime would add the no property when no present (by inferring the value from the index).

normalizeFieldInfo() takes partial field info, but has no information about the current index. Also, field numbers are arbitrary. It is best practice to keep a sequence, but in the real world, there are often gaps or numbers out of order. Seems quite a lot of work for rather little gain.

Opening new ticket for "Replacing kind string literals".

Thanks for the feedback!

from protobuf-ts.