Closed smalers closed 2 years ago
Embedding might benefit from Angular Elements? See this SO article.
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.
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.
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:
npm
packagesowf-app-dev-ng
repository can be tested in one place (although testing in final application is also often necessary)The library code is expected to support the following applications:
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:
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:
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:
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:
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.