This seems like it should generate the typescript classes that were added to the native types feature export types but it doesn’t. I have a simple class Campaign and it doesn’t generate unless I add a route to it. Is this by design?
var nativeTypes = this.GetPlugin<NativeTypesFeature>();
// use an attribute to include extra classes
nativeTypes.MetadataTypesConfig.ExportTypes.Add(typeof(Campaign));
nativeTypes.MetadataTypesConfig.ExportTypes.Add(typeof(DataEvent));
Right it still needs to be part of the services contract, the ExportTypes is for exporting suppressed types like built-in System Types and Enums.
You could create a dummy class that holds all the types you want generated, e.g:
public class Dummy {
public Campaign Campaign { get; set; }
public DataEvent DataEvent { get; set; }
}
public class MyServices : Service
{
public object Any(Dummy request) => request;
}
Thanks, I read several of your posts about that and as well about the native types feature, it just seemed like it should work. I really think the native types feature should export any classes that are added there, is that something you’d consider before I open a feature request or should it be something new added to that feature?
Why can’t you make it as part of your Service Contract? I don’t want to risk breaking some projects when the solution is to include it as part of your Services Contract which is only what Add ServiceStack Reference is supposed to generate.
That’s a fair question and I have a use case that will probably become more popular. Consider you have a front end all based on service stack (typescript), everything works great. Now you want to add in something like SignalR which is also sending messages out using that same front end. All of these messages are classes that need to be exported to typescript as well. Of course, we can dummy up services as you mentioned but that doesn’t really seem like the best way to achieve this. I know there are some VS extensions that can do this as well but one thing I love about SS is it is already doing the code generation.
I wasn’t suggesting a breaking change, but it would seem like 99% of the code already exists to generate the typescript classes and adding something like:
nativeTypes.MetadataTypesConfig.ExplicitExportTypes or something similar that could pick up those extra cases or a bool that by default would be set to the existing behaviour and then could be changed to allow for this case. I know I’m not the only one as there were other SO and forum posts you’ve answered on this and I wanted to ask before creating a feature request.
It’s extremely important that the Add ServiceStack Reference feature only publishes services included in the Service Contract and not pollute the generated Types with internal system types or unrelated types. It’s very easy for the type count to explode if we included all types in ServiceModel and all types it references.
There is an easy workaround for the few times you want to publish types outside your Service contract, create a DTO holder, call it something that represents your use-case like:
public class SignalRTypes {
public Campaign Campaign { get; set; }
public DataEvent DataEvent { get; set; }
}
public class MyServices : Service
{
public object Any(SignalRTypes request) => request;
}
I’m against adding complexity and introducing potential breaking changes when there’s already an easy and intuitive way to do what you need. We don’t need to change or pollute features for these niche use-cases when we can already use the existing functionality to do it.