Data Segregation

Outcome

We should know which pages are the easiest to refactor as there’s not a lot of data overlapping.

Tasks

• Create an Obsidian Vault for Data Segregation

• Make a list of all routes in the app by creating files

• Make a list of all values in a store (only 2 levels deep)

• Make a list of all APIs

• Map routes to values in a store

• Map store values to APIs

• Create User Stories with those routes that are the easiest to do

1. Overview of the current situation with routes
2. Where we want to end up with after refactor
3. Problems that we may encounter while refactoring
4. Plan

Docs

Overview

This document is to demonstrate the current situation with how we use store in the web application, what we want to achieve with the refactor, showcase some potential issues that we may or will encounter during that process and a plan on how we can do it.

Current webapp’s situation

As of today (19.02.2024), we have 35 pages in the customer facing web app and ~ 66 values in a store. Some of these values are just local ones and some other ones are backend data that are fetched on initial load or when visiting a particular route. Some of the values that are stored in a store are generated based on the the backend value.

Where we want to get to

We want to align the web app with our frontend blueprint and that means:

• Make sure that data displayed in the application is always up to date with the backend and those values are not stored in a local store.
• We separate data layer from the UI layer
• (Optionally) we have better structure of routes as currently, everything is flat. This will allow us to minimise re-renders and have a better flow of the app. However, that may require re-design of the app, which is not our goal

Issues that we may have

Inconsistent data between legacy and modern app

The only issue that we may have is an inconsistent behaviour between applications. The legacy app does not always re-fetch data on initial load and that means that if something changes on the backend, someone has to re-login to see those changes.
This is what we want to fix so re-creating the same behaviour in a modern app is a no-go. The modern app will use Tanstack Query which solves this problem, but it does not fix the issue for the legacy app and users will still have to re-login to have correct data.

What we can do to partially fix this issue is to persist data for Tanstack Query and create our own wrapper for it so both, Vuex and Tanstack Query persisted data are read and saved the same way. However, if someone will visit the route that is part of the Legacy app, there is a chance that the data is still not up-to date, so it is worth keeping that in mind. The ideal scenario for this would be to refactor the legacy app to always refetch data when it’s read from the store or to add Tanstack Query, but that will be longer than it is needed.

Shared values between views

Some values in a store are used by various different routes. Those are going to be the hardest to refactor taking the above into consideration. The best approach for that would be to start with routes that use store values, that are not used by many routes and this is the approach we are going to take with this.

Some features are currently on hold and not in the app

There are some features that are currently on hold (auth migration), and because code for those is not in the app but is on a separate branch, we may either have to re-write those to use the new app or to not touch pages/routes that are part of this feature.

Pages that are no longer needed

Within the app, there are some pages that are no longer needed or were left in case we need them. We need to discuss whether they are needed or we can skip them.

Approach

To be able to refactor the webapp and fix its problems, we have to use Strangler Fig patternwhich will allow us to migrate the legacy code by gradually replacing specific pages which, will allow us to replace all old system’s features by strangling the old system. A higher-level plan on how we want to achieve this, you can find here.

We identified routes, store values, mapped them together to understand how interconnected they all are. Here is the graph of all routes

And here is a graph of all store values

And this is how it all looks like together

When you look at this, initially, it looks a bit intimidating but there’s actually quite a lot of data that we can read from this graph and will help us to identify which parts of the app will be the easiest to refactor and which ones will be the hardest. For example, by looking at calculators route, I can see that on this page, values from calculators store are used and that there are nested routes of this route. Most of these routes use values from calulators store but there are few routes that are using value from the auth store (auth/isUserLoggedIn) and that is calculators/affordability-calculator, calculators/calculation-history and calculators/cost-calculator. Let’s ignore for now why this is required.

When you hover over that value, it shows you all routes that are using this value and as you can see on a screenshot below, they are actually not part of calculators sigh… That means we have to have a similar value in the new app which, in context of auth, should be fine. However, that means that the auth needs to be refactored first, because lots of these values will be used by quite a lot of other pages and that includes the root of the app.

So, based only on this example, we confirmed that shared values and features that are currently on hold may (or may not) get in a way. At least, this needs to always be considered.

Pages that are not always visible

Not all routes are accessible for the user and they depend on the value in a store. The best example are onboarding routes (investor-type, investor-type-detailed etc.)

Features of the highest importance

Our webapp has some features that are more important than the others. The main ones are Investments, Savings and Calculators, then we have settings, documents etc.

Order

Now that we know what the above and potential issues we can have, we created a list of routes that we need to refactor and the order

1. Auth store and Wrapper
   1. We can read the token from the local storage
2. Dashboard
3. Calculators
4. account-settings
5. Documents
6. investor-type & investor-type detailed
7. Login, forgot password and sign up related pages