Refactor code ported from Java to retain consistent package naming

[smalers]

This issue focuses on code organization housekeeping, which is important because multiple products are using the same code. In particular, we want it to be as efficient and robust as possible for code to be shared between the InfoMapper that Josh is working on and the Angular demo application that Sofia is working on. Ideally, classes can be copied from one repository to another with no additional modification. Any interdependencies between classes should work without code modification.

Some Java classes were ported to TypeScript in order to efficiently implement needed functionality in InfoMapper. Although the Java code could probably use some refactoring, it has generally performed well over many years so is a good start. The code that was ported focused on time series classes (TS, MonthTS, etc.) and associated supporting classes (DateTime, TimeInterval, etc.). The Java code lives in multiple repositories, which have a hierarchical relationship and allow sharing the libraries between applications. In particular, initial code was ported from:

• cdss-lib-common-java - foundational utility code
• cdss-lib-models-java - more specific model-specific code

Within the Java repositories, typical packaging naming hierarchy was used with the left-most part being an organization identifier (RTi for Riverside Technology, inc.). Other Java libraries may use the domain name but that was not used at the time. To the right of the organization is the logical package naming to group classes. For example, RTi.TS.TS is the package path to the TS class used for time series.

For TypeScript, it would be helpful to keep the same package organization and class names, so that it is easy to compare with Java. For "namespace uniqueness", the repository name (essentially a library name), organizational part, and remaining package/class allow classes to be included and kept unique from other names. See the article on Typscript namespaces and modules.

The ultimate approach may be to package code as modules that work within the npm registry or other library approach. However, short of that, copying classes from one Angular project to another can be done to allow development to continue. Below are some recommendations to evaluate to do this:

1. Make the TypeScript class names exactly match the Java names, to avoid confusion. If this is an issue, we can evaluate.
2. Retain the right-most package levels by using folders to organize classes, similar to Java code.
3. Assume that some module/namespace design will be implemented in order to isolate the ported code from other packages that may be used. This is particularly important when dealing with somewhat generic class names like DateTime. In other words, something more than just dropping classes into an Angular project in a flat folder structure may be needed. Assume that in the future, code from one or more of the existing Java repositories will be packaged into one or more Angular repositories. For now, the code will have its master in the InfoMapper repository and copies made in other projects, if modified, will be migrated back to InfoMapper.
4. Consider using a top level "namespace" of openwaterfoundation. A TypeScript class might then have a path openwaterfoundation.TS.TS. To organize the code, a top-level folder src/openwaterfoundation could be created with other folders and files beneath, for example src/openwaterfoundation/TS/TS.ts. I am tempted to use cdss instead of openwaterfoundation in order to keep consistency with the Java repository names. However, OWF is investing in the development and will be maintaining the code. The organization to some degree is arbitrary and serves as a "tie breaker" for namespace resolution.

The above needs to be evaluated by Josh before coming to a final decision. I think we need to consider what the code would look like given the approach that is used. Code should be consistent with typical Angular conventions. This will impact Sofia and her work.

[cnlane]

This might be helpful to consider: https://angular.io/guide/styleguide

[smalers]

I looked though the guide and the section on libraries is useful.

What I have found with library development is that it can be a pain to develop the library independent of an application. For TSTool, the source code to libraries is available during TSTool development so that if I change a library to support the application, it happens together. The Java libraries are separate repositories and are cloned into different application workspaces as needed.

For InfoMapper, if we used it as the main development tool for a library, then hopefully you have the source code and can create an npm module for distribution. So, is the library in the same repo as InfoMapper, for example in a folder? Or would it make sense to put into a different repository?

I don't think we have to create a library now unless it helps out, but using a library approach for common shared TypeScript classes seems like it would make sense in the long run. We'd have to figure out how distributing the npm module internally would work.

[Nightsphere]

This has been completed, and any more imported Java code will follow the same package naming. Closing the issue.