Configuration tables should take regular objects

[carlo-quinonez]

Currently, configuration tables require a class definition.

I see this line is where we use the new keyword with the configuration table parameter, which explains why the parameter has to be a class.

declare function ConfigurationTables(tables: new (...args) => any): <T extends new (...args) => GenericThing>;(target: T) => void;

I'm still coming up to speed with advanced TS types, but is there a way to to use Object.create(arg) instead of new (...args)?

Also, the logic for handling configuration tables is also over here in the transformer repo. Do you think it's worth considering moving code for building the entities into a single repo?

[BogdanMihaiciuc]

The reason for this is that regular object literals don't support the same kind of syntax that classes do. For example, you can't apply decorators to object literal properties and you also can't have properties without specifying a value for them so I settled on using an anonymous class in this case.

The transformer repo is separate because it makes it easier to update projects with new transformer versions (or downgrade) and also easier to manage the projects themselves since the transformer code is mostly unrelated to the thingworx project itself.

[carlo-quinonez]

The reason I asked about this was because of the eslint rule max-classes-per-file. Obviously we want to enforce 1 Class per file, but the anonymous class counts and throws an error in eslint. I've disabled the rule for now.

I found an old eslint issue to ignore ClassExpressions (ie. anonymous classes). I'm following up on the eslint repo about this...

[BogdanMihaiciuc]

I'm open to suggestions here if you think a different approach could yield good results. When I developed this the anonymous class seemed like the best approach given the requirements.