Skip to main content

MilMove ADRs

For new ADRs, please use the template in the sidebar. This list contains all of the architectural decision records for the MilMove client and server application.

📄️ 0048 Use a consistent file structure for front-end code

Currently, the front end code is in a state of mid-reorganization from one file structure to another. However, without a specific plan in place, this reorganization risks losing momentum, and over time could result in the code being indefinitely split between two different file structures. This makes future work on this codebase more confusing and increases the risk for mistakes to be made. Therefore, the purpose of this ADR is to establish a plan and certain guidelines for moving the reorganization forward, hopefully at an increased pace.

📄️ 0053 Use React Query for Office App API interactions

We are currently making heavy use of Redux in both the Office app & customer-facing app to manage API data in the browser. While there are other valid reasons to continue using Redux, it does put a lot of overhead on our code to handle fetching data, providing the correct data to the correct UI components, and deciding when to invalidate or re-fetch data that has become stale. This article (Why I Quit Redux) explains pretty well why this is less than ideal, and also proposes using a library called React Query as an alternative.

📄️ 0054 Use CSS to highlight unfinished features

For the MilMove demo on 8/4/2020, the decision was made to use a feature flag to conceal unfinished work, in order to reduce confusion on the part of the client as to what work was complete vs. not yet finished. The MilMove project encountered a similar issue in 2018 and decided to use a low-lift solution of highlighting unfinished work with a yellow background via a CSS class applied to UI elements. This decision resulted in increasing transparency around feature status, lowering confusion, and helped improve overall client communication around project progress.