A behind-the-scenes look at the development of OPUS by iungo’s User Profile
Since the Information, Advice, and Guidance (IAG) OPUS user profile came solely under my control, it has gone through a number of extensive changes.
The addition of our own custom dropdown menus, my custom date input component and half a dozen more of our own functional components – to name a few. This has not only massively expanded our front-end capabilities across the entire app, but also allowed the full journey of adding an element to a user’s profile to be implemented, including optional details like grade, school, etc.
In addition, many quality of life fixes like loading indicators and clear filter buttons have been added as well as dozens of bug fixes.
Learning while developing…
As someone new to iungo, as well as React and Typescript in general, creating clean, polished and effective functional components for the user profile has been a constant challenge. Every week, as I learn new practices and tricks, I wish I had done something differently the week before.
This issue was compounded by a lack of consistency in the code and documentation of the four main profile pages.
These pages have a very similar layout and yet because the Tech team was working on them independently, they were all written in different ways. This was partly due to different coding styles among team members, but also because our agile methodology meant the profile was continuously and organically growing. And, as we learned new things, newer pages would be implemented differently.
This was solved by creating a template page that all aspects of the profile would be based on. The pages are now written in a consistent style and structured in the same way. This means that if we ever wanted to add a new feature or fix a bug across all the pages, it can be done using the same solution rather than four.
It also means future team members will be able to get to grips with how the user profile works much more easily.
Getting to know React Native
Another regular challenge in my role is the fickle nature of React Native.
If it doesn’t do something you want out of the box then it often requires complicated and sometimes downright tedious workarounds. Oftentimes, developers will recommend installing third party assets to avoid these workarounds, but we prefer to develop our own components from scratch whenever possible.
This helps us avoid instances where the third party stops maintaining their asset and it stops working months or even years down the line.
And so this led to the development of an “Off-Click Tracker” component that allows our dropdown menus to detect when a user has clicked off them, making them close automatically. The tracker can be wrapped around any component, detect any click event on or off it, and execute any function when the event is detected.
This ended up being a highly scalable and reusable solution to the problem. And, in my opinion, quite elegantly written when compared to other solutions that can be found online. I think the tracker’s success is also testament to my personal development at iungo Solutions.
Hitting my stride
I’ve now been working on OPUS by iungo for a few months and I feel I’m starting to hit my stride in React Native. Though, I still have a couple of hiccups in me…
One time I spent two hours trying to fix a query bug along with the entire tech team and it turned out the whole problem was caused by me accidently copy-and-pasting an extra space in a query key.
I’m sure we all have one of those stories!
Hiccups aside, I’m developing my Front-End development skills quickly and have been given a great platform to do so.
I’m looking forward to further challenges and new responsibilities.
– Matthew Ettridge, Front-End Developer