You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OOM domain definitions carry the C# and DB types, but we still rely on hardcoded translations to generate their TS counterparts, and the behaviour is currently different between the model and service generators. The latter doesn't actually use anything from the OOMs and rely 100% on the C# definitions, which may not necessarily come from the model. It works fine when the non basic types we use are entity types from the model, but when they aren't we're not sure how to translate them from C# to TS.
Currently, the ModGen generates "any" when it doesn't know the TS type associated to a domain, and the ServiceGen generates an import based on the C# namespace for any non standard C# type it encounters (there are special cases for Focus and static reference types, but this is designed to work out of the box for model generated types)
Having said that, we can't simply add TS types to the domains to solve this issue, so we'll need a way to specify custom C# -> TS translations that will be used by both generators. It could be added to the unified config file from #9.
The text was updated successfully, but these errors were encountered:
OOM domain definitions carry the C# and DB types, but we still rely on hardcoded translations to generate their TS counterparts, and the behaviour is currently different between the model and service generators. The latter doesn't actually use anything from the OOMs and rely 100% on the C# definitions, which may not necessarily come from the model. It works fine when the non basic types we use are entity types from the model, but when they aren't we're not sure how to translate them from C# to TS.
Currently, the ModGen generates "any" when it doesn't know the TS type associated to a domain, and the ServiceGen generates an import based on the C# namespace for any non standard C# type it encounters (there are special cases for Focus and static reference types, but this is designed to work out of the box for model generated types)
Having said that, we can't simply add TS types to the domains to solve this issue, so we'll need a way to specify custom C# -> TS translations that will be used by both generators. It could be added to the unified config file from #9.
The text was updated successfully, but these errors were encountered: