Is it ever a good idea to share a single ngrx store encapsulated in a library between two separate Angular apps? Our business logic layer is extremely calculation-oriented (spreadsheet-like), and so it fits naturally into a reactive model. The trouble is, I'm not sure of the best way to split this code up so our team doesn't have to maintain two parallel codebases that implement the same logic.
Background: I'm currently running an AngularJS hybrid application (which has already been ported to Typescript) and will be starting on a new app written in Angular 5. Unfortunately, we will need to share a substantial amount of business logic and services between these applications: the hybrid app is currently built on a Flux-like architecture with stores, action creators, and components (using the .component syntax) while I intend to build the new application on @ngrx/store. To bridge the gap, I was thinking of creating a third project which would be a library that depends on @ngrx/store that would encapsulate the actions, store, reducers, and effects on which both applications would rely. Is this a good idea, or terribly misguided?