The Sorcery of Building a Cross Platform Design System Architecture

Rate this content
Bookmark

When we want to build a “cross-platform mobile app” the answer always is React Native but what if you want to build a “cross-platform app” that runs across mobile and browser? Here’s where React Native falls short. react-native-web is trying to bridge this gap to some extent but the primary requirement is to write your code in React Native which gets converted to the web, but that itself has a bunch of downsides and the biggest one being - forcing mobile app developers to understand how browsers work. In this talk, I’ll share how we are building a true cross-platform architecture without using react-native-web for our design system at Razorpay.

This talk has been presented at React Day Berlin 2022, check out the latest edition of this React Conference.

FAQ

The main goal of Razorpay's design system is to create a unified design language system that works cross-platform, allowing developers to implement components that function seamlessly on both web and native platforms.

The pros include leveraging the specific expertise of native and web developers, and utilizing native capabilities of each platform. The cons involve redundancy in code and effort, as multiple teams solve similar problems, leading to less unified APIs.

Although React Native Web allows for code to be written once and used across platforms, it posed challenges in debugging and did not fully meet Razorpay's need for a single, unified API that works seamlessly across web and native platforms.

Razorpay approaches the development by creating a single API that works across platforms, ensuring components are tested individually on each platform, and using bundlers and file extensions to manage platform-specific files effectively.

Razorpay utilizes tools like Metro and Webpack for bundling, Jest for testing, Rollup for separate platform bundling, and TypeScript for managing types, ensuring each part of the system is optimized for the respective platform.

Razorpay ensures accessibility by creating alias maps for accessibility properties that differ between web and native platforms, and using a runtime function to resolve the correct properties based on the platform, ensuring compliance with accessibility standards.

Kamlesh Chandnani
Kamlesh Chandnani
23 min
05 Dec, 2022

Comments

Sign in or register to post your comment.

Video Summary and Transcription

This Talk discusses the development of a cross-platform design system architecture. It explores different approaches and proposes a unified API that works across web and native platforms. The Talk covers techniques for resolving files and declarations, configuring bundlers, and testing for both web and native platforms. It also highlights the bundling of TypeScript types and handling accessibility for different platforms.

1. Introduction to Cross-Platform Design Systems

Short description:

Hi, everyone. I'm Kamlesh. I work as a principal product engineer and the design systems and infrastructure tools team, which is part of the platform's team at Razorpay. Today I'm going to talk about the sorcery of building a cross-platform design system architecture. We wanted a design language system that works cross-platform. The first approach was to have individual teams building for each platform.

Hi, everyone. I'm Kamlesh. I work as a principal product engineer and the design systems and infrastructure tools team, which is part of the platform's team at Razorpay.

So, today I'm going to talk about the sorcery of building a cross-platform design system architecture. So, disclaimer before I start, this is all about our experience and how we approach this problem space based on the factors. And it doesn't necessarily mean this is the only way.

So, let me start first with the problem statement. We wanted a design language system that works cross-platform. Now, we started with what other approaches that we have at hand. The first approach was have individual teams building for each platforms. That's natural. You have different teams, different platforms, and you have different teams working on those platforms.

2. Approach to Cross-Platform Design Systems

Short description:

We explored different approaches, including utilizing the expertise of individual teams for each platform and leveraging the native capabilities offered by each platform. However, none of them met our needs for a unified API that works across web and native. So, we came up with our own approach, aiming for a Nirvana State where developers could implement code once and have it work seamlessly on both web and native platforms. We identified the need for a unified API, a testing center, separate bundling for each platform, and shipping TS types with individual bundles. To demonstrate, we will implement a typographic component that works on both platforms, starting with the web platform.

And then we started to state the pros and cons of each of the approaches. So, the pros for this approach was we have expertise of people for each platform. Let's say a native developer was working on an iOS app, they would have their own set of expertise. And then another web developer was working on the web platform, they'd have their own set of expertise. So, we wanted both. And we could also utilize the native capabilities offered by each platform because there are a lot of capabilities that, let's say sometimes native platforms offer you, but the web platforms don't, or they have exposed it a different way. So, we wanted to utilize these capabilities natively by each of the platforms.

The cons for this approach is multiple teams for building the same thing, right? Like you have multiple people who are kind of solving the same problem over and over again. And then we had redundant code for similar things. The third one was less unification of APIs, right? Because now your APIs would be redundant or they would be created by different teams.

Then there was another approach which was use React Native Web, of course, which is very famous option these days. So, it had pros, which was you could write once and use across web and native, which is what we were looking for. Secondly, it was similar APIs across platforms. The cons were React Native Web to write for web too, right? Now challenges for React Native Web to debug web things. It's like native first and then penetrate with web.

Now, none of the above fit our needs. We were looking for something that has one same API and work across web and native, utilize native capabilities offered by each platform and then we had we wanted app devs to do what they are best at and web devs to do what they are best. So, basically our desire at Nirvana State was what if a dev had to implement below across platforms for them it should be like for us it would have been like if you take this subcode and copy paste it for both web and native, it should just work. That was like you could say our Nirvana State.

So, how did we approach this? So, we listed down what all things we need to tackle. So, the first one was same API that should work across platforms, then we wanted testing center because even though you write once and run on both the platforms we still wanted to test our components on both the platforms individually so that we should not miss any of the bugs on either of the platforms. And then we wanted to bundle each platform separately so that you know, your web bundle is not messed up with react native and vice versa because otherwise it will just break. And we also wanted to ship TS types along with each of these individual bundles.

Yes, so let's see things in action by implementing a typographic component. So, this is the component that we implement and it should work as it is on both the platforms. This is basically and state that we'll be doing during this session. Now, let's start with the first one, same APIs that work across platforms. So, if you think about it, the API for this would look something like, let's say if you want to design or create a typographic component, what would the API look like? It would have ID color, font family, font size, font weight, these are the very basic properties for a typographic component. So, usually what you'll do is you'll start with implementing platform by platform. So, the obvious first thing to start is let's just start implementing it on web.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Design Systems: Walking the Line Between Flexibility and Consistency
React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
The Talk discusses the balance between flexibility and consistency in design systems. It explores the API design of the ActionList component and the customization options it offers. The use of component-based APIs and composability is emphasized for flexibility and customization. The Talk also touches on the ActionMenu component and the concept of building for people. The Q&A session covers topics such as component inclusion in design systems, API complexity, and the decision between creating a custom design system or using a component library.
Build a Design System with React and Tailwind CSS
React Summit 2022React Summit 2022
27 min
Build a Design System with React and Tailwind CSS
Top Content
This Talk discusses design systems and how to build one using React and Tailwind CSS. Tailwind CSS provides utility classes for building complex layouts without writing CSS rules. Custom colors can be added to the Tailwind CSS config file, and font styles and text sizes can be customized. The entire Tailwind CSS configuration can be customized to meet specific requirements. Base styles can be added to the config file itself using a plugin. Reusable components can be created with Tailwind CSS, allowing for easy customization of size and color.
Walking the Line Between Flexibility and Consistency in Component Libraries
React Summit 2022React Summit 2022
27 min
Walking the Line Between Flexibility and Consistency in Component Libraries
This Talk discusses the comparison between Polaris and Material UI component libraries in terms of consistency and flexibility. It highlights the use of the action list pattern and the customization options available for the action list component. The Talk also emphasizes the introduction of a composite component to improve API flexibility. Additionally, it mentions the importance of finding the right balance between flexibility and consistency and the use of types to enforce specific child components.
Find Out If Your Design System Is Better Than Nothing
React Summit 2022React Summit 2022
20 min
Find Out If Your Design System Is Better Than Nothing
Building a design system without adoption is a waste of time. Grafana UI's adoption is growing consistently over time. The factors affecting design system adoption include the source mix changing, displacement of Homebrew components by Grafana UI, and the limitations of Grafana UI's current state. Measuring adoption is important to determine the success of a design system. The analysis of code through static code analysis tools is valuable in detecting and tracking component usage.
Dialog Dilemmas and Modal Mischief: A Deep Dive Into Pop-Ups
JSNation 2023JSNation 2023
10 min
Dialog Dilemmas and Modal Mischief: A Deep Dive Into Pop-Ups
The Talk discusses the use of dialogues and popovers in web development. Dialogues can be modal or non-modal and are now accessibility-supported. Popovers are versatile and can be added to any element without JavaScript. They provide suggestions, pickers, teaching UI, list boxes, and action menus. Modal and non-modal dialogues and popovers have different behaviors and dismissal methods. Browser support for these features is expanding, but there are still open questions about positioning, semantics, and other use cases.
Type-safe Styling for React Component Packages: Vanilla Extract CSS
React Advanced Conference 2023React Advanced Conference 2023
19 min
Type-safe Styling for React Component Packages: Vanilla Extract CSS
Watch video: Type-safe Styling for React Component Packages: Vanilla Extract CSS
Today's Talk introduces Vanilla Extract CSS, a type-safe styling method for React applications. It combines the benefits of scoped styling, zero runtime overhead, and a great developer experience. Vanilla Extract generates a static CSS file at build time, resulting in better performance. It is framework agnostic and offers a powerful toolkit, including Sprinkles for utility classes and CSS utils for calculations. With type safety and the ability to define themes and variants, Vanilla Extract makes it easy to create efficient, scalable, and maintainable design system component packages.

Workshops on related topic

Rapid UI Development in React: Harnessing Custom Component Libraries & Design Systems
React Advanced Conference 2022React Advanced Conference 2022
118 min
Rapid UI Development in React: Harnessing Custom Component Libraries & Design Systems
Workshop
Richard Moss
Richard Moss
In this workshop, we'll take a tour through the most effective approaches to building out scalable UI components that enhance developer productivity and happiness :-) This will involve a mix of hands-on exercises and presentations, covering the more advanced aspects of the popular styled-components library, including theming and implementing styled-system utilities via style props for rapid UI development, and culminating in how you can build up your own scalable custom component library.
We will focus on both the ideal scenario---where you work on a greenfield project---along with tactics to incrementally adopt a design system and modern approaches to styling in an existing legacy codebase with some tech debt (often the case!). By the end of the workshop, you should feel that you have an understanding of the tradeoffs between different approaches and feel confident to start implementing the options available to move towards using a design system based component library in the codebase you work on.
Prerequisites: - Familiarity with and experience working on large react codebases- A good understanding of common approaches to styling in React