You are right, we have 2 parts to the problem.
- Making it modular
- Refactoring to a new tech stack.
To make it modular, we are proposing to bundle the existing code in bahmni-common as a single js and html bundle and include that as a dependency. Which does not seem difficult, with the working POC we have. The important part is that, this new bundled code will just be used by appointment scheduling, so we will bundle the dependency required by Appointment Scheduling alone.
Once we have bundled and moved out the common code, we can include all the other dependency as npm packages.
At the same time, we would like to understand the difficulties you have faced, to ensure we did not miss on anything significant.
I think we should keep the server side and frontend side splitting as 2 different concerns, as that will itself be a big chunk to redesign and refactor. And we do not want to combine server side and frontend refactoring.
Also, we are looking to do the Part 2 along with Part 1, because we are going to make an investment towards redesigning the UI, so instead of investing in an old piece of code, we want to do it the new design on React.
“For the React part, I did not see a path/approach articulated to migration of the existing features/codebases” -> I would like to understand what other details are you seeking, the document has a mention of the timeline.
Angular and react both being JS framework, I do not foresee any significant performance bottle neck. The react components would anyways get complied to angular components/directive, until the majority of code is in Angular JS.
Form Builder codebase is like a separate module as compared to appointment scheduling, as no point in time we will end up loading 2 versions of react on the browser, as these modules are not interlinked in anyways. So, it would not be a technical concern, to upgrade form-builder first and then migrate appointment scheduling.
We should understand the how we be more aligned to the micro-frontend architecture while performing this refactoring. Though, we would like to do that migration at a later point.