Leaflet is an excellent library for creating interactive maps. It's one of the core technologies I'm using in FrontierNav, and one of the most mature browser-based mapping libraries out there. FrontierNav eventually moved over to React, so ideally I'd want a mapping library that also used React. Sadly nothing's really as mature as Leaflet, so I stuck with it.
React and Leaflet Interoperability
One of the issues I came across after moving the project over, was trying to integrate React's update logic with Leaflet's custom markers, dubbed "DivIcons". For a good year, I left the logic intact, using custom logic to manually manipulate DOM elements by subscribing to a Redux store. It worked but it was complicated and a pain to revisit.
Eventually I moved over to react-leaflet, a library which wraps Leaflet and provides pre-made React Components to represent various Leaflet components (Maps, Tile Layers, Markers, etc.). This was a huge improvement. While it was still using Leaflet's API under the hood, the update logic and state diffing could be handled in React like every other component in the app. Perfect!
Except, there was one major issue. react-leaflet does not support React-powered DivIcons and it doesn't plan to. The aim of react-leaflet is to be a thin layer on top of Leaflet's API without any additional features. So, what can I do?
Previously, FrontierNav only had one visualisation: a map. With the new Affinity Charts for Xenoblade 2, I've been looking into various approaches to present the same information along side different visualisations.
For example, showing both the Affinity Charts, and allowing users to navigate to the map while retaining their view of the "entity" they're looking like, like the Affinity Reward or the Enemy requirement.
There are a few candidate ideas I'll be fleshing out a bit.
One's a windowing system like any Operating System with the visualisation as a background.
Another is a "bubble" system, kind of like Facebook's Android app and Samsung's Touchwiz window system.
Data Imports
More raw data has been coming out for Xenoblade 2, so I've started writing a parser to transform it into a compatible format for FrontierNav.
Keeping track of all of this work and keeping it organised has been a bit of a pain. I'll be organising frontiernav-data to be a bit more, well, organised.
Open Source
Due to the number of moving parts and complexity of the project, open sourcing it as-is isn't as worthwhile. With the lack of documentation it'll be difficult for anyone to contribute or make use of it.
So, to get the web client into a state that can be open sourced, I've been splitting out bits into their own project. A mono-repo approach has worked well for this as it means I don't need to juggle multiple Git repos and branching dependencies.
Next Up
I'll be continue to work on the things outlined above. There's a lot to do but I'm getting a better idea of where to take FrontierNav by doing it.
Having to play new games, enjoy the first playthrough, then figure out their intricacies while also extracting data and building new features in a timely manner is really difficult.
Once Xenoblade 2's data is imported and guides are stable, I'm thinking of moving onto more classic games. The main reason being that all the data is already available and I can use them as an opportunity to build FrontierNav into a state where it's a lot easier to add new, recent games.
What games? There's quite a few. I've had an itch to replay Golden Sun Books 1 & 2 recently.
With my new found appreciation for the old web and aged websites, I happened to come across Beaker, an open source web browser focused on peer-to-peer sharing of websites. It allows you to browse websites at a directory-level and redistribute them. The user experience reminds me of browsing websites before the last decade where sitemaps and directory listings were public and openly shared.
I came across The Video Game Museum (VGM) recently while doing some research for a side project. It's a website dedicated to archiving the history of video games. I'm personally really interested in the video game preservation and archeology scene, mainly due to the sheer nostalgia I feel when remembering the past.
The web is a place full of passion and imagination. However, over the last decade, it's slowly started to lose this essence. At least, for me. With the advent of massive social media platforms by Google, Facebook, Twitter and many more, browsing the web has been restricted to a handful of portals. Now and then I'd follow a link elsewhere but immediately bounce back, visiting the same websites over and over.
It wasn't always like this. The freedom of the web and its many dedicated communities is one of the factors that drove me to where I am now. And I want to rediscover those forces again.
In this series, I'm going to explore the web again. Find the stuff I appreciate, and actually put some thought into it. I don't have any strict plans for it, no candidates, no structure. I'll just go with it and see where it takes me.
Moving over to this approach has made the dependency between my components and stylesheets a lot less complex. I'll be going through this migration to give some context to my conclusions.
CSS Modules are often touted as the next step from CSS methodologies like BEM (Block Element Modifier). In this article, I'll explain why BEM should still be used alongside CSS Modules for consistent and intuitive styling.
January's been a productive month. Behind the scenes, I've continued to move the application towards a more pluggable approach. It's going to be a slow process as I work on other features like new game guides and improve the user experience.
Xenoblade 2's data is fed through a spreadsheet which makes it much more easier to edit. The process is still a work in progress but I've got a good idea of where to take it. Once it's ready, I'll be moving the other games from the previous JSON-based approach to this new one.
I didn't make a release post about "Spoiler Gates" since it's pretty simple. The app can now show/hide spoilers based on the user's preference. This won't mean much for existing guides, but I can take it into considering for new guides.
In the fast moving technology stacks of JavaScript, Nightwatch has grown to become one of the most popular front-end end-to-end testing frameworks around. It's an all-in-one solution allowing you to write tests without additional dependencies and effortlessly run them either locally or remotely.
We've been using Nightwatch at Unruly for a year now, and while it's not perfect, it's proven to be a lot more convenient than similar frameworks.
One of the problems we've had with Nightwatch is related to how we debug tests. During deployment, we'd run tens of tests and only one may fail. Finding this failing test and running it in isolation has always been tedious and time consuming since there's no IDE integrations to easily jump around the code base from Nightwatch's output.
This is where Night Patrol comes in. In the simplest sense, Night Patrol does what we would've done manually. It keeps track of various inputs sent to Nightwatch and keeps track of the resulting outputs. In this article, I'll be going through how Night Patrol works and how it's used.
