This obviously could have been a lot of smaller PRs, but my goal was just to get the foundations laid and everyone unblocked as soon as possible! As adding duplicate searching obviously expands the scope a lot, I wanted to make some conceptual and structural tweaks here as well that I think make the app a lot easier to digest for folks just onboarding to it.
On that note: I really recommend not reviewing this PR by looking at the diffs. It's going to be way to confusing and not very informative! There are so many files changed, but many of those are just renames, re-orgs, or other small tweaks that then affected a lot of files.
Rather, I recommend you just check out the branch locally and consider it more as a whole!
Also, as UI goes, I just put a bunch of filler that shows the current state. The real components can be made in the coming PRs!
I'll call out some noteworthy things below.
Reworking app boot and hydrating all the data
Relevant directories:
app/
static-data/
url-history/
Bugomattic is a little bit of a funny beast in how it boots up! We have load data from the site from a couple of places.
We have some one time configuration that comes off the server. I've started calling this "static data" is this PR. This includes...
The "reporting config", or all the feature areas and their issue-reporting details.
The list of available repo filters when duplicate searching. This is new as of this PR.
We also track the main state of the app in the URL history. This allows people to use bookmarks, alfred workflows, sharing links, etc... So on initial load, we have to parse the state from the URL and load it as well.
The tricky thing is that the URL history load depends on the static data load, as we often have to validate pieces of that URL state against what is in the static data. And we also don't want to show users the app before we finish parsing and loading the URL history state, because then they might see the app just change on them unexpectedly!
So we now show a loading indicator until everything is set up: both the static data and the state from the URL. All of this is now streamlined (so it happens in the right order) in app/use-app-data-hydration.
Creating Two App Pages
Relevant directories:
active-page/
duplicate-searching-page/
reporting-flow-page/
The app now has two main pages it can display: one for duplicate searching, and one for the reporting flow.
To keep in line with our current state tracking mechanism and to support the route handling in MC, we're just tracking which page is active in a new piece of Redux state.
In the future, we can look at adding react-router to handle these main page loads, but it will require reworking some core MC configuration, and some extra reworking of our state tracking.
Redux state for duplicate searching:
Relevant directories:
duplicate-results/
duplicate-search/
I've added all the needed redux state and handlers (and some placeholder filler UI components too) for duplicate searching. I've split the state over two top-level nodes:
One for tracking all the search parameters
One for tracking the results of the search requests
This keeps the state nodes small and focused. It also helps with tracking state in the URL, as we do it by top-level node, and we only want to track search parameters, not results, in the URL.
Testing Instructions
I've updated all the unit tests to get them to passing! ✅
You can pull the branch, yarn, and yarn start to play around with the app locally. Note the UI will be pretty bare bones, but everything will work together, including URL tracking!
I'd also love any feedback on the current state of the repo after these changes: what parts are confusing to understand? Does anything seem over-engineered? Do you have any suggestions for other ways to introduce these foundational changes?
What Does This PR Add/Change?
First of all, I am so so sorry 🙇 😅
This obviously could have been a lot of smaller PRs, but my goal was just to get the foundations laid and everyone unblocked as soon as possible! As adding duplicate searching obviously expands the scope a lot, I wanted to make some conceptual and structural tweaks here as well that I think make the app a lot easier to digest for folks just onboarding to it.
On that note: I really recommend not reviewing this PR by looking at the diffs. It's going to be way to confusing and not very informative! There are so many files changed, but many of those are just renames, re-orgs, or other small tweaks that then affected a lot of files.
Rather, I recommend you just check out the branch locally and consider it more as a whole!
Also, as UI goes, I just put a bunch of filler that shows the current state. The real components can be made in the coming PRs!
I'll call out some noteworthy things below.
Reworking app boot and hydrating all the data
Relevant directories:
app/static-data/url-history/Bugomattic is a little bit of a funny beast in how it boots up! We have load data from the site from a couple of places.
We have some one time configuration that comes off the server. I've started calling this "static data" is this PR. This includes...
We also track the main state of the app in the URL history. This allows people to use bookmarks, alfred workflows, sharing links, etc... So on initial load, we have to parse the state from the URL and load it as well.
The tricky thing is that the URL history load depends on the static data load, as we often have to validate pieces of that URL state against what is in the static data. And we also don't want to show users the app before we finish parsing and loading the URL history state, because then they might see the app just change on them unexpectedly!
So we now show a loading indicator until everything is set up: both the static data and the state from the URL. All of this is now streamlined (so it happens in the right order) in
app/use-app-data-hydration.Creating Two App Pages
Relevant directories:
active-page/duplicate-searching-page/reporting-flow-page/The app now has two main pages it can display: one for duplicate searching, and one for the reporting flow.
To keep in line with our current state tracking mechanism and to support the route handling in MC, we're just tracking which page is active in a new piece of Redux state.
In the future, we can look at adding
react-routerto handle these main page loads, but it will require reworking some core MC configuration, and some extra reworking of our state tracking.Redux state for duplicate searching:
Relevant directories:
duplicate-results/duplicate-search/I've added all the needed redux state and handlers (and some placeholder filler UI components too) for duplicate searching. I've split the state over two top-level nodes:
This keeps the state nodes small and focused. It also helps with tracking state in the URL, as we do it by top-level node, and we only want to track search parameters, not results, in the URL.
Testing Instructions
I've updated all the unit tests to get them to passing! ✅
You can pull the branch,
yarn, andyarn startto play around with the app locally. Note the UI will be pretty bare bones, but everything will work together, including URL tracking!I'd also love any feedback on the current state of the repo after these changes: what parts are confusing to understand? Does anything seem over-engineered? Do you have any suggestions for other ways to introduce these foundational changes?
Issues
Related to #
Closes #