Tech Debt - HackMD

# Tech Debt ## Top Focus: Reusable + Self-Contained Components **Rationale:** Would like to see a heavy focus on identifying commonalities all throughout the app and making components (both smaller and larger ones) out of them, as well as common styles, and enforcing a standard of using them. We have a large number of groups within ReusableComponents within DSGUI, but most are not documented, and I do not believe everyone is aware of what each one is. Every time we recreate a view where a reusable component could have been used, we increase development time, and we make the codebase unnecessarily larger, making it harder to maintain and harder to find what we are looking for. There may be variations on appearance of things that can be considered common components; this should be negotiated with design to keep as consistent as possible, but ultimately should be handled with view modifiers when those discrepencies occur. Regarding the self-contained aspect, I want to aim to keep components from creating side effects on the containing views where they exist. It should know just enough to handle its own logic and presentation. --- **Phase 1: Identify** - Start with going through each item in the ReusableComponents group and getting a screenshot so visually we know what we have to work with to start: https://jira.dcsg.com/browse/CMT-6651 - Based on the findings above, determine if we are actually using everything inside ReusableComponents, as well as if we are using them in all the applicable locations (i.e. are we re-implementing something different where we could use one of these components? This can include it needing minor refactoring) https://jira.dcsg.com/browse/CMT-6705 - Go through the app and begin making notes on components and styles that can (and use some discretion on what _should_) be reusable, that is not potentially covered by any existing reusable component/style. A litmus test might be "If this were re-usable, would it be easier to use at each existing call site, and would it save development time later for future features?" These can be small things or large things. It could be as simple as a pattern we notice where we place specific views in specific ways repeatedly in the app in the same layout, or it can be something a bit more complex (to give some examples, some that come to mind are overlap in appearance for items in cart vs items in order history; another is considering forms and if we can simplify how those are built out- can we break out specific fields and compose them together in different forms as needed). Some underlying models might be different, which can pose a challenge to combining things, but it is worth investigating if they can use a common protocol. https://jira.dcsg.com/browse/CMT-6706 --- **Phase 2: Create/Update/Remove** *TBD- These will be tasks to create new components, rewrite existing ones, and remove unused ones* --- **Phase 3: Implement/Document** *TBD- These will be tasks to switch out implementations to use these common components, and document any new or undocumented components*