Sprint 26 – The best laid schemes of mice and men
This update is going to be more technical than usual, I set out with the plan to finish last weeks clean up, then start working on profiles but ended up going down a buggy rabbit hole.
As you can see it’s been… quite the rabbit hole! So whilst a lot has happened in the last 2 weeks and the code is like a billion times cleaner – I’ve not actually achieved anything visual.
Before we get into this mess let’s get the other stuff out of the way!
Sunday 7th March 1900-2100 GMT / 1200-1400 PT / 1500-1700 ET
A brutal exploration and survival game for 1-10 players, set in a procedurally-generated purgatory inspired by viking culture. Battle, build, and conquer your way to a saga worthy of Odin’s patronage
This sprint our Average position went up from 22.7 to 21.7!
Impressions are up from 3k to 3.64k and Click through is up again slightly from 2.4% to 2.6!
Domain authority is holding steady at 28!
OK, so now we’ve gotten the Game night and stats out of the way – let’s talk about this Rabbit hole!
First up was introducing some context providers.
Originally, I wanted to do this to handle profiles so that when you change your profile picture / details, especially when you do it from the website or similar – it’s reflected through the app!
But to make that work, I had to change all of my components to functional components – well I didn’t HAVE to but the whole thing would have been an unmanageable mess if I didn’t.
So whilst I was making the change it made sense to introduce context for Authentication, API access and the overarching app too!
It took a bit of time but I managed to refactor login, registration and introduce AppContext, AuthContext and APIContext.
Then I thought to myself – why am I using 3 different navigation stacks?
- One for unauthorized users
- One for authorized users
This is the structure before the work I did, as you can see – everything is basically a descendent of a single router and settings sits in the unauthorized zone.
The Authenticated Router is wrapped inside a Drawer router – it’s all a bit of a mess…
So my first challenge was separating it all out into something much cleaner with a simpler structure, I decided to separate “Authorized” from “Unauthorized” and then give them their own routers.
I then moved the settings Screen into the Authorized zone and built a context provider for the Drawers.
This process has helped separate concerns significantly and reduce the code complexity but it came with it’s own unique problems!
The main one being state management and the drawers. You see for the drawers to work they need to be dynamic – I need to be able to add and remove things on the fly otherwise when a new user logs in OR a chat room disappears – we can’t show it.
The problem with this approach is that with the way React works, every time you update the state of a context provider (In this case the drawers context) all of it’s children rerender…
So i tried implementing memo’s and purecomponents but found that these still re-render when you’re using a context provider and consuming it in the same class.
When that didn’t work, I did what I should of done in the first place honestly – split out the components into Drawer components.
And no more issues!
There were a considerable amount of other changes all relating to these core changes but the end result is a much cleaner, easier to digest code base with some structure – something we’ve been sorely lacking until this point.
If you want to see how much changed out of morbid curiosity you can check out the commit here: https://github.com/SoSa-Community/app/commit/72f2ecbab76adceca0b30ed3650569db1d59ac60 on the github repo!
Anyway, I hope you enjoyed this read! I still have a bit more to go, a few more components to move into functional components but the bulk of the work is done now and I hope this next sprint I can get profiles ready!