FrontierNav Weekly: 2nd March 2020

Streamlined Merge Requests

Merge Requests can now be merged with a single click and completed in a few seconds. Previously, I needed to re-deploy the application and wait around 10 minutes, so this should speed up the editing process drastically.

It's not polished yet. Things flicker as it changes state and the error messages aren't very helpful. I'll need to put in some time before exposing it to anyone else (such as chosen Editors).

More Streamlining

The next part in making Merge Requests more streamlined is chaining them. Currently, merges are standalone. Once you make one, you need to throw away your open changes or duplicate them to create another one. Both approaches causes potential conflicts if any of your previous merge requests are merged as you're working on different states.

So, like local commits in source control, I'll be implementing a way to create a chain of merge requests using the same set of open changes. When a request is merged, those changes before it are discarded automatically to avoid conflicts.

Everything is still static

It's worth mentioning that while there is now an entirely web-driven merge flow, FrontierNav is still entirely static. There is no database. The merge flow just takes a client-side computed blob, provided by an authorised user, and points to it as its new database.

FrontierNav within FrontierNav

The Data Tables are at a point now where they can be used for pretty much any dataset. So I've moved out the hard-coded games from source code to a separate application database as a form of dogfooding.

So now, FrontierNav itself is a 'game' within FrontierNav... Which makes complete sense. It has its own forums and it even supports the same merge request flow if anyone wants to make changes to it.

I was hesitant to use the term 'Game' to describe games in FrontierNav's source code for this reason. They are essentially namespaces of arbitrary sets of data. At one point I called them 'worlds' but the migration never completed so I had both. Now I'm mostly using 'namespaces' which might be a bit too generic but it gets the point across. So that's three different names for the same thing.

Beyond Games

With all of this data refactoring, it's true that FrontierNav can easily host any dataset. Movies, Books, whatever. But I'll be sticking to games for now until I'm satisfied that the goal -- to improve game guides -- has been reached.

Next Up

Once I'm done polishing these new features, I'll be adding more data to some existing games (such as Xenoblade 2) in order to further improve the editing flow.

Thanks for reading.