Move map component to common library

[smalers]

Introduction

We have made significant progress using the common library for shared Angular code integrated with the InfoMapper. However, recent challenges have pointed out a few major design challenges that need to be addressed head on. Otherwise, continued development will likely be more technically challenging than desired. The following sections attempt to discuss important design question that need to be addressed. This issue can be used to collect thoughts on the design before taking action. There are several InfoMapper projects to finish and more starting soon so having a plan is necessary to minimize disruption.

Why Use Libraries?

Some reasons to use libraries for code are:

• allows the code to be shared among different applications using standard development protocols such as npm packages
• compatibility of components can be ensured through design and testing (rather than including various third-party packages in each application)
• swap out of components can occur over time to provide updated features to all applications that use the library
• minimizes the need to rewrite code and copy and paste code between projects
• library code such as that maintained in the owf-app-dev-ng repository can be tested in one place (although testing in final application is also often necessary)
• it may be easier for developers to collaborate on separate library rather than working on the same code in an application (this is a reason for multiple libraries)

The library code is expected to support the following applications:

• InfoMapper - full application
• InfoMapper "Lite" - single embeddable map and other variations
• common library development/test application
• applications similar to InfoMapper but with custom dashboards and analytics tools (for example applications like SNODAS, if use of the common library provides benefits over custom application development)
• one-off prototypes for evaluating new products and proposals

Library Contents

It was originally thought that separate libraries should be created for major components. However, complexities of doing so and benefits gained may be limited for OWF work. Instead, the common library may instead be better if it is larger and contains a stack of standard integrated components. This will allow for better integration of preferred components without circular dependencies between libraries (dependencies for preferred components are in the same library). Other libraries can still be added if they are of secondary nature and integrate well with the common library using standard interfaces. The common library is proposed to contain the following "preferred" stack of technologies:

• Angular Material UI components (PrimeNG or other UI library that is incompatible with Material UI is not expected to be included in the common library)
• Leaflet for mapping component, with associated code to handle OWF map project functionality
• Plotly for graphing (other visualization packages could be included or rely on separate plug-in libraries)
• Showdown for Markdown to HTML conversion
• Other core components?

The above components provide a full-featured and integrated technology stack that allows complex applications to be created.
Additional libraries could be added for additional visualization tools, either in the common library or "plug-in" libraries, for example:

• D3
• Other charting libraries.

Plan for Evolving InfoMapper

The InfoMapper currently depends on the OWF common library. However, there are issues with circular dependencies, such as common library components calling the map component, which only exists in the InfoMapper. Moving the map component to the common library will address some of these design challenges. The following are technical considerations that need to be addressed:

• What code will be moved to the common library (e.g., map component) and what code will remain in InfoMapper (e.g., main shell with menu configuration and routing).
• How much of remaining functionality will be supported by common library components and utility classes (e.g., for the above)?
• How much of an application's design will be guided by common standards, such as name of application configuration file?
• How should design review be done, for example to agree on package (folder and file) names for code components?
• How can development be done efficiently with library and application so that there is not a significant time necessary to rebuild library, deploy, rebuild app, deploy, etc.? If more code is in the common library, will it be possible to work more in the development library project and only update InfoMapper periodically?
• How will automated testing be implemented to ensure code coverage and improve quality for releases?
• Should the InfoMapper repository be restructured as a multi-project workspace or will the above changes eliminate that need? See the next section.
• How much time is necessary for the migration? It is difficult to make large changes when project deliverables are due.

Plan for Other Applications

In addition to full InfoMapper and the common library development application, there is a need for other applications.
Until a second application is implemented, it may be difficult to know that the approach taken for common library and InfoMapper will actually support multiple applications. The following approach focuses on developing an embeddable single map application that is suitable for a targeted information product. Technical considerations include:

• Is the name of the product InfoMapper with a modifier such as "InfoMapper SingleMap" or similar? The app folder, etc. would need to be determined.
• Is the application a separate repository or a separate app project in the InfoMapper repository (such as implementing a multiple project workspace where multiple apps are in the same repo?
• Can the common library and common map component be used in the application and InfoMapper? That is the goal and it would be helpful to be confident of this before the redesign.
• Can an Angular map application be embedded in a web page or does it require a separate web page and URL?
  • It may be appropriate to always have a separate URL and single-page website so embeddability may not be a show stopper.
  • If embedding with iframe is used, are there issues such as retrieving data from third-party websites? In this case, this approach may only be appropriate if all data are hosted on the same domain.

Beyond the above, there are no current plans for other applications. It may be that most of the future development is related to enhancing the common library, InfoMapper, and single map application.

[smalers]

Embedding might benefit from Angular Elements? See this SO article.

[Nightsphere]

After the initial Map Component migration from the InfoMapper to the Common library, there were multiple errors that occurred, which was expected. All were obvious and borderline trivial except one:

The ng-packagr compiler claimed that the newly created leaflet entry point containing the Map Component was already
exporting a member with the same name that the dialog entry point was attempting to export.

After some testing, it was determined that because 2 separate entry points contained pipes, this error was being thrown. Combining the entry points into it's own entry point and adding them to a PipeModule resolved the issue.

[Nightsphere]

This has been implemented and been in production for a few months. I'm confident in the structuring of this now, and understand how ng-packagr deals with compiling the library files using entry points. Closing the issue.