Allow custom JsonSerializerSettings to be provided to a HostingModel

[bradchristensen]

Currently in my application I don't want to use the CamelCasePropertyNamesContractResolver when serialising JSON to and from the Node.js process, but this is a readonly setting in each of the existing HostingModels (see

JavaScriptServices/src/Microsoft.AspNetCore.NodeServices/HostingModels/HttpNodeInstance.cs

Line 29 in f2f67fe

ContractResolver = new CamelCasePropertyNamesContractResolver()

). It threw me that this was the default behaviour, although I don't think it's a bad thing. We should be migrating our app to use it in future.

I'm not familiar with how everything fits together so I can't propose any implementational details but would be interested to know if it would be a possibility to make this configurable when instantiating a HostingModel. Or is it expected that a custom HostingModel should be created to configure this?

[SteveSandersonMS]

The tricky thing is that various parts of JavaScriptServices need to be able to pass parameters from .NET into Node to control things like how server-side prerendering works, how Webpack integration should work, etc. If we couldn't rely on a particular serialization format, then it would be difficult to have anything work out of the box.

One possible solution would be to allow the serialization format to be overridden on a per-invocation basis, and then the standard libraries (e.g., for prerendering) would always override it with their preferred format (camelCase), and would preserve your chosen format by double-JSON-encoding any data you supply to prerendering (where the inner encoding is whatever serialization format you've specified). However, the drawback is that this would perform much worse because of doubling the encoding and parsing work at both ends.

If this gets requested by many more people then we can certainly consider implementing it, but I kind of hope not because of the way it would reduce efficiency :(

Possible alternatives for you would be:

• Doing your own double-encoding (i.e., JSON-stringify your data with whatever settings you want on the .NET side, pass the resulting JSON from .NET into Node, and use JSON.parse in your Node code)
• Or, more easily and probably more efficiently, use https://www.npmjs.com/package/change-case-keys in your Node code to convert the incoming objects into whatever naming style you prefer.

[dazinator]

I'd like to prevent null properties from being serialised.

I have a typescript compilation options class in C# which has many nullable properties:

 public class TypeScriptPipeOptions
    {      

        /// <summary>
        /// Allow JavaScript files to be compiled.
        /// </summary>
        public bool? AllowJs { get; set; }

However when these are passed to node, it is serialised like this:

"options": {
    "allowJs": null,
    "allowSyntheticDefaultImports": null,
    "allowUnreachableCode": null,
    "allowUnusedLabels": null,
    "alwaysStrict": null,
    "baseUrl": null,
    "charset": null,
    "declaration": null,
    "declarationDir": null,
    "diagnostics": null,
    "disableSizeLimit": null,
    "emitBOM": null,
    "emitDecoratorMetadata": null,
    "experimentalDecorators": null,
    "forceConsistentCasingInFileNames": null,
    "help": null,
    "importHelpers": null,
    "inlineSourceMap": false,
    "inlineSources": false,
    "init": null,
    "isolatedModules": null,
    "jsx": null,
    "jsxFactory": null,
    "lib": null,
    "listEmittedFiles": null,
    "listFiles": null,
    "locale": null,
    "mapRoot": null,
    "maxNodeModulesJsDepth": null,
    "module": 1,
    "moduleResolution": null,
    "newLine": null,
    "noEmit": null,
    "noEmitHelpers": null,
    "noEmitOnError": null,
    "noFallthroughCasesInSwitch": null,
    "noImplicitAny": true,
    "noImplicitReturns": null,
    "noImplicitThis": null,
    "noImplicitUseStrict": null,
    "noLib": null,
    "noResolve": null,
    "noUnusedLocals": null,
    "noUnusedParameters": null,
    "out": null,
    "outDir": null,
    "outFile": null,
    "paths": null,
    "preserveConstEnums": null,
    "pretty": null,
    "project": null,
    "reactNamespace": null,
    "removeComments": null,
    "rootDir": null,
    "rootDirs": null,
    "skipDefaultLibCheck": null,
    "skipLibCheck": null,
    "sourceMap": true,
    "sourceRoot": null,
    "strictNullChecks": null,
    "stripInternal": null,
    "supressExcessPropertyErrors": null,
    "supressImplicitAnyIndexErrors": null,
    "target": 1,
    "traceResolution": null,
    "types": null,
    "typeRoots": null,
    "version": null,
    "watch": null
  }

These options, once within the node process, are passed to a typescript compiler.

For values such as nullable booleans, just the fact that the property exists (even though it's value is actually null) it's enough to act as a flag for the compiler or whatever you pass those options to.

I am going to work around the issue by cleaning up the options on the nodejd side by looping throgh the object and removing null valued properties, but a more efficient / cleaner solution would be to allow us to control the serialisation of our arguments at the Invoke level.

I wouldn't want to modify the global default serialisation settings, just per invoke - different invokes to different scripts may want to use different serialisation settings.

[SteveSandersonMS]

If you want to control the serialization yourself, a quick way of doing that right now would be just to pre-serialize the JSON as a string in the .NET layer, using whatever serialization style you like. Then you'll receive a string on the Node side and can deserialize it (e.g., with JSON.parse) yourself.

This approach cleanly separates RPC-layer serialization from application-layer serialization, so it's safe even if the two subsystems have different serialization requirements.

[dazinator]

Ok will do. Thanks.