Here at Mercari the vast majority of our frontend web applications are written using React. Web technologies are notoriously volatile so attending conferences like React Summit allows us as engineers to keep up to date with developments in the ecosystem. Here I’ve put together some of the highlights from the event and a summary of the most significant upcoming changes.
Impact: Growing as an Engineer – Iris Schaffer
Kicking off the conference, Iris gave an interesting insight into what it takes to become a successful engineer. As well as your technical impact, she explained organizational impact can also take a big role and core skills such as communication, accountability and decision making are vital. One interesting statistic that was quoted, 70% of learning occurs whilst on the job with the remaining 30% split between social interactions and formal learning events (not a great indication for the worth of this article 😅). For the sake of advancing as an engineer, it’s therefore paramount that we tie our goals to our work.
Keeping Sane with React Micro-Frontends in Production by Applying Observability – Konstantinos Leimonis
By utilizing React Error Boundaries and adopting structured events, Konstantinos explains how we can better isolate errors to improve observability across micro-frontends and allow for split ownership.
In our JP marketplace product we are currently using a monolith style architecture with a single React Error Boundary that reports to Sentry. This allows us to identify issues our customers are encountering and escalate those issues to the relevant team. For larger projects and highly independent teams I believe the strategy of utilizing multiple error boundaries could prove effective however comes with considerable complexity so should not be adopted lightly.
How React Applications Get Hacked in the Real-World – Liran Tal
By using React we are completely safe when it comes to sanitizing user input right? Liran scarily points out that in fact although React does cover most cases for us, dynamic href attributes are not encoded so can be susceptible to XSS attacks 😱. It’s therefore important that if we are to expose some user input via href we should always prefix the protocol (
https://) and use relative paths!
The Art of Functional Programming – Anjana Vakil
Inherently when developing web applications we always have some form of side effects, writing to the DOM, making network requests etc, so the question is how can we reap the benefits of functional programming? Anjana discusses how we can wrap our pure core code in an imperative outer shell that handles side effects. In addition to this she demonstrates how through the use of self-invoking pure functions we can also iterate in a functional manner. For those interested, a full run through of her content can be found here.
Routing in React 18 and Beyond – Delba de Oliveira
This for me was the standout presentation and sets the stage for the future of React applications. The team behind Next.js have raised a RFC that puts in place a pattern for more versatile applications with benefits of both a multi-page and single-page application. The core principle is that of utilizing React Server Components and nested layouts (for example a sidebar wrapping multiple pages) to allow full control of where content is generated, be it on the server-side or client-side, whilst preserving common components and their state on navigation. This I believe will be a huge paradigm shift for web development with the decision of whether to render content on the server or client side no longer being restricted to an entire page but definable at every level of the component tree. For those with a spare 10 minutes I would highly recommend reading this accompanying blog post for more details.
Walking the Line Between Flexibility and Consistency in Component Libraries – Siddharth Kshetrapal
Siddharth discussed the evolution of Github’s design system and recommended that composition can be the most effective solution when handling components with a large number of variations. Configuration based APIs with data passed as props can be effective for simpler components but over time can become convoluted with poor scalability.
Sharing is Caring: (How) Should Micro Frontends Share State? – Eliran Natan
One of the most difficult tasks when considering how to implement a product with micro frontends is how to share state in a scalable fashion. Eliran highlights that one way to mitigate this complexity is to first correctly define teams and micro frontends based on user stories as opposed to other naive strategies such as screen based division. For example having a “purchase” micro frontend can allow for the entire user flow of adding an item to the cart and purchasing an item to all reside in one application, reducing the amount of communication required between different micro frontends. For propagating updates he then draws comparisons to the microservice event bus and discusses how we can use the native
CustomEvent in browsers to effectively communicate between micro frontends using event handlers. For maintaining a common state we should try to keep the store separate from each micro frontend to reduce the dependence of one on another and help define a clear explicit API.
It seems like we’re finally beginning to see some more mature patterns for server-side rendering and micro frontend architectures. These two advancements should give teams greater control over ownership and give us a more effective toolbelt to improve metrics vital to our users such as time to First Meaningful Paint by selectively choosing what is rendered server or client side.
Here at Mercari over the next few months we hope to utilize and build upon these patterns to strengthen our web product and move from a JAM stack architecture to also incorporate server-side rendering. Through this we hope to unlock several SEO improvements and provide faster initial page loads for our users.
For this non-trivial task and others, we’re always on the lookout for talented engineers so check out our open positions to see how you can get involved.