Unified Navigation
At WayUp we run several different technology stacks on different areas of the website. For example, WayUp started with Django based views, then as the need for a single page app arose, we began to incorporate AngularJS. When the popularity of React started growing, the team made the decision to continue any future development in React. This includes hosting our blog, community guide, career questions and answers, job seeking, and many other projects. We’ve tried to solve for the problem of maintaining consistent behavior for common features across the different tech stacks. Before this undertaking we would often copy and paste across projects, leading to inconsistent styling or a different look and feel altogether.
Most users didn’t notice the difference and the code was tolerable for a long time, but as we began to mature, our products were becoming unmanageable, especially when we wanted to start thinking about layering other strategies that we were employing elsewhere.
If we wanted to be able to A/B test changes in our navigation bar across all products, then we would have to build additional features to support that for each project. For example, if a new link were to be added, multiple teams would have to be involved to ensure that all links were updated to point to the correct location. This was also the case when a simple verbiage change was requested. It was a cumbersome and clumsy effort that was achieved, but often the consistency throughout was sacrificed. This is a picture showing many of the different variations of the navigation bars that were being maintained; on our blog, public job pages, logged in, logged out, career questions portal, company pages, press page, etc.
After a few brainstorming sessions, we came up with an elegant solution that was actually quite easy to implement: create the navigation bar as a standalone React app that could be mounted anywhere. We created a new entry point in our webpack.config.js for creating a bundle that would mount the navigation bar and its dependencies.
Adding the additional entry tells webpack to create another bundle. The starting point defined as NavigationBarRoot.js allows for Webpack to package everything necessary for mounting our navigation bar as a standalone React app into a bundle file. This turned out to be an effective solution, as now our main React project could continue to use the navigation bar as a standard React component <NavigationBar />.
And when the resulting bundle navbar.bundle.js loads and mounts to the page, it also uses the same <NavigationBar /> component, without all of the extra dependencies from the main React app. Now we can continue to develop in our main React project, and deploy the changes everywhere at the same time because both bundles receive updates at the same time.
Since the navigation bar is a React app, we’re able to present different navigation bars based on what role the user occupies, whether they are unauthenticated, an employer, or a job seeker. When a user logs into our site, we give them an authentication cookie. So once the navbar.bundle.js is loaded, we check to see if an authentication cookie is available, and if it is we make an API call to load that user’s information. From there we use a switch statement to load the proper navigation bar.
A caveat to this approach is the implications for Search Engine Optimization (SEO) strategies. Since our navigation bar is loaded via Javascript, it means that any web crawlers will not see the HTML that is generated by our external navbar.bundle.js. For us, it was fine because we left the existing navigation bar HTML in place and when our bundle mounts to the page it is overwritten, allowing for the web crawlers to receive important links to other pages, but also giving our end users a consistent navigation experience. Another consideration is that there is now another bundle to think about and load instead of having each project natively render the HTML/CSS/JS required for a navigation bar.
The navigation bar bundle project has been a success for us here at WayUp. The benefits of developing in one place and deploying to all projects at once far outweigh any downsides. It also allows us to follow our brand style guides more consistently without much effort.
Do you have any thoughts or comments? Feel free to email us at team@wayup.com. Want to join the team? Visit https://www.wayup.com/joinus
