Create Typescript intellisense problems

[lucamorelli]

Hi, I was trying to use the Create Typescript Intellisense file features, but I'm finding a bit difficult to use extensively in some situation and I was thinking to add a few features:

1. camelCasing of the properties exposed in the typescript class. serializing and deserializing via mvc action sometimes the data are not correctly bound, so I would like to expose this as an option, with the other option of convert them unchanged.
2. exposing the generated entities as interfaces. I can use them from typescript client side but I haven't found a way to create a new instance using the new operator: I have to write var myObject = { prop1= 1, prop2 .....} giving a value for each property untils typescript is happy, and this is a bit annoying when the class has a lot of properties. To have the option to generate as class may be of help in some situation I think
3. if a class contains inside an instance of another object this is not converted and is defined as myProP : {}, and this limits intellisense when you have contained classes..
4. Use of the TypescriptModule attribute for every class, this is a limitation if I want to compile contained objects.

For the first 2 points the solution is not complicated, but to solve the last two I though a different approach:

1. choose a folder inside the project (ApiModels for examples ).
2. every csharp class inside this folder ot subfolder is automatically converted to ts assigning the namespace as module name.
3. now that we're sure that every class is available as ts when can add inner references inside classes, and if optionally add a prefix if someone doesn't like to have the same name.
4. add an helper class for the entities when, using Automapper you can fix the serialization issues (for example I often have problems serializing and deserializing dates).

What do you think? May be a nice idea?

[madskristensen]

@am11 @gcastre What do you think?

[am11]

Undoubtedly, this is a nice suggestion.

There are some mature tools such as TypeScripter and TypeLite for C#-TS conversions, which even generate interface definitions from compiled assemblies. Compared to these tools, WE2013's implementation is quite basic.

WE uses reflection to enumerate the code. For casing fixes, they can be delivered without much hassle. The rest of them are doable as well, but TBH, the development experience is not super-pleasant (hint: it is Reflection all over the place!)

In WE2015 (https://github.com/madskristensen/WebEssentials2015), however, typescript conversion can leverage Roslyn. With that, the chances of getting this entire feature on steroids are quite high and we can advance pretty swiftly.

IMO, since both versions of WE are implementing this feature using different approaches, we should first implement in WE2015 using Roslyn, and then for VS 2013 (where Roslyn can be optionally installed), back-port the code to WE2013 with a runtime check if Roslyn not present, show dependency missing notification in menu/option for "advance features". This will save duplicate effort and save a lot of development time figuring out what is and isn't possible with Reflection, which can be better spent on perfecting our Roslyn :muscle:.