FrontierNav Weekly: 20th July 2020
Changes
- "Open Changes" now collapses when there are too many changes.
- This avoids the momentary UI freeze when opening the change list if you just want to see counts and send a Merge Request.
Work in Progress
- Improving Merge Request flow (read below)
Support the project
These past few weeks, FrontierNav has 1 new patron: cd!
If you would like to support FrontierNav, please consider donating on Patreon. Doing so helps fund development and keeps the project going. Thank you.
Improving Merge Request Flow
One of the core issues with the existing Merge Request flow is the way it deals with page reloads. If you've made some changes, they're applied to the data and also recorded individually. The data is too large to store locally, so only individual changes are stored.
The problem is, on a page reload, all of these changes need to be safely re-applied. That could take a while if there are hundreds of changes, and it gets really tedious when you have to go through it multiple times; especially if you've reloaded accidentally.
To add to this, when creating a Merge Request, since those changes need to wait for my approval, you still need to hold on to them (and re-apply when needed) until they're accepted as part of the official data. So if you want to make further changes, it'll pile onto your previous changes -- which you've already sent a Merge Request for -- and just cause a mess.
The only way I can see of improving any of this is to essentially implement basic version control. Which isn't unexpected -- I called them "Merge Requests" based on how developers send pull requests and merge requests on GitHub and GitLab.
So considering this is a solved problem on other platforms, I've mostly been researching existing solutions and setting up a plan to deliver it incrementally.
Next Up
First step of the plan is to remove the "Conflict" dialogue when I've approved a Merge Request. Say someone sends a Merge Request adding a "Potion" entity. If I approve it, that change -- which is still stored locally -- will conflict saying "Potion" already exists and a modal will pop-up saying "Conflict, this may or may not be a problem." (in short). Of course, it's not a problem since they're the ones that added the Potion, but FrontierNav currently has no way of knowing that. Not a great experience.
Thanks for reading.