Simplify imports for enums.

[robin-anil]

protobuf.js version: 6.2.1

Enums are a common thing used across our code. in v5. I would be able to do things like

import { MyMessage } from 'protos';
if (something === MyMessage.Type.CAT) {
   // Do something.
}

The same thing now is

import root from 'protos';
const MyMessage = root.lookup('MyMessage');
const Type = MyMessage.lookup('Type');

if (something === Type.values.CAT) {
}

I like the lookup pattern for messages, I understands its pros. But for enums its very clunky when you have values in between.

Can enums live in its own shadow hierarchy? which makes it easy to do something like.

import { MyMessage: { Type } } from 'enums'; 

if (something === Type.CAT) {
   // Do something.
}

[dcodeIO]

The reason why there aren't any magically created object trees anymore basically is that there is no way to make this work the same with typed dialects like TypeScript, which requires proper types on everything.

What do you think about adding

/**
 * Gets the values of the nested enum with the specified name.
 * This methods differs from {@link Namespace#get} in that it returns the enum's values directly and throws instead of returning `null`.
 * @param {string} name Nested enum name
 * @returns {Object.<string,number>} Enum values
 * @throws {Error} If there is no such enum
 */
NamespacePrototype.getEnum = function getEnum(name) {
    if (this.nested && this.nested[name] instanceof Enum)
        return this.nested[name].values;
    throw Error("no such enum");
};

so you can do the following (if Type is a direct child of MyMessage):

if (something === MyMessage.getEnum("Type").CAT) {
}

Side note: You can also use lookup and its variants on any namespace, including Type instances.

[robin-anil]

Thanks that's better.
However, still I don't like that dynamic interface is it doesn't throw error during import. Explicit import checking is something we have gotten used to and I would love if there was some way of keeping that...

[dcodeIO]

These methods throw: lookupType, lookupService, lookupEnum and getEnum
These don't: lookup, get

Does this help?

[robin-anil]

¯_(ツ)_/¯ Still a runtime check. I am thinking if there is something I can add so that the whole thing barfs during babel bundling.

[paralin]

Interesting idea to use static checking for this somehow, I like the idea but I'm not quite sure how we can implement that.

[robin-anil]

This idea is very raw: I feel like there is a middle ground between the current static-module (3.2MB in our case) and json-module (56KB)

I think you can create exports within json-module by not just export $root but the entire hierarchy as symbols. For all Types, Services and Enums.

I mean it is easy for me to do the following, Therefore I believe we can do something like that in the generated json-module itself whereby we can make these import statements work.

import * as protobuf from 'protobufjs';

const root = protobuf.Root.fromJSON(require('core/dist/core.json'));
  		  
const protos = {	
  ...root.lookup('tocktix.messages').nested
};
  		  
module.exports = protos;	

And for bonus, if we can somehow eliminate subsets of protos what is not in the dependency tree, the whole compiled bundle will be smaller. We have a huge proto tree for the server side.

But our clients depending on what APIs they call use different subsets of them. If we can somehow atomize and let babel/uglify be able to eliminate dead-code, that would be wonderful, But not required. I would take syntax and safety over this.

[paralin]

So why not just generate Typescript definitions for the static code, and actually generate + execute the static code at runtime?

By that I mean, generate a strongly typed TypeScript tree for the expected output of protobuf.Root.fromJSON. Then don't actually compile that to code. Just use fromJSON at runtime.

[robin-anil]

@paralin Could you mock a example for me. I would like to see what that looks like. I am trying to convert a large react codebase from v5-v6. I am also trying to automate this conversion, examples help me visuale the refactor.

[paralin]

This would have to be a few steps, I think.

Given a proto:

message MyMessage {
  string my_string = 1;
}

Step 1 is to generate typescript interfaces for these:

interface IMyMessage {
  myString?: string;
}

Then step 2 is to allow Type to take a Type<T>:

let myMessage: Type<IMyMessage>;

The T would be used for the return type of asJSON, as the argument type for create, validate, encode, etc.

Next, generate a tree:

{
  MyNamespace: {
     MyMessage: <Type<IMyMessage>>root.nested.MyNamespace.nested.MyMessage,
  },
}

Then usage would be:

generatedTree.MyNamespace.MyMessage.encode({myString: "test"})

The myString literal would be TypeScript validated, as the argument type would be of IMyMessage.

[robin-anil]

Yes! The generated tree portion. This is exactly what I had in my mind, which I started the conversation when I said shadow hierarchy. The trouble we have right now is nesting Types, Enums together, so we will have to create such trees independently for Types, Services and Enums. And we can do that in JS too... Doesn't have to be just typescript.

[dcodeIO]

Well, now that you mention it, it's theoretically possible to expose everything uppercase (there are no other uppercased properties) on the reflection objects so that a .d.ts from a static module could be used with reflection. encode, decode are the same anyway. Generated static classes would benefit from also having create in addition to make it mostly have the same runtime API as there is no constructor otherwise for runtime-generated types. This should, if I didn't miss something, make static and runtime classes mostly interchangeable - despite not having typed access to reflection (which isn't in the static .d.ts) of course.

[robin-anil]

❤️ I strongly support that theoretical possibility and would encourage to be made a reality. A clean API goes a long way; this is one of the last remaining kinks with v6.