BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News How Paypal Enables UI Component Sharing at Enterprise Scale

How Paypal Enables UI Component Sharing at Enterprise Scale

This item in japanese

Bookmarks

Dong Chen, Paypal engineer, recently discussed the challenges behind component sharing at the enterprise level and the solutions that Paypal is using to address those challenges.

Chen summarized the problem as follows:

Although [component-based] Web frameworks make it easier to share components, sharing doesn’t happen by default. Challenges still exist, especially at an enterprise level, which demands extra efforts to coordinate among teams working on various products across organizations. In reality, even discovering components created by other teams is hard.

Reusing components may bring significant benefits. Reusing well-designed quality components gives a baseline in terms of functionality, behavior, and performance that a particular team at a particular moment may not have the vision, skills, time, or resources to replicate. Localization, internationalization, and accessibility are important features to design for that benefit from specific knowledge that may not be readily available in a given team.

Furthermore, developers reusing components may focus on the larger behavior of the application being developed. Chen quoted a research paper suggesting savings in engineering time ranging from 40% to 81%.

Designing and implementing reusable components may however be expensive. Butler W. Lampson gave, in a chapter of the Computer Systems: Theory, Technology, and Applications book an appreciation of the design costs:

Design is expensive, and reusable designs are very expensive. It costs between ½ and 2 times as much to build a module with a clean interface that is well-designed for your system as to just write some code, depending on how lucky you are. But a reusable component costs 3 to 5 times as much as a good module. The extra money pays for generality […], simplicity […], customization […], testing […], documentation […], and stability […].

Lampson further reflected on reasons behind failures of reusable components projects and mentioned three main reasons: the absence of a business model, the cost to understand and use components, and the fact that components may have conflicting interfaces.

Chen supplemented four aspects: discovery, sharing, quality baseline, and community collaboration. Chen explained that the most common asks on Paypal’s Slack channel revolve around where to find existing components, how to ensure that a given component meets the needs, or that the documentation is up-to-date.

Chen proceeded to describe the solutions in use at Paypal:

Paypal solution to component sharing
(source: Chen’s blog post)

Paypal opted for using component playgrounds (like Storybook and others) to build and render components, due in part to their ease-of-use, customization abilities, and the control it gives to components’ authors.

Paypal uses Component Explorer (home-made solution) to display available components that are interactive, documented, version-tracked, quality-audited. The explorer also allows Paypal to measure the usage of components within Paypal as a proxy for quality and to give back credit to the component’s author. Importantly, the component explorer facilitates discovery by enforcing a centralized hosting platform which can be queried by tags (like checkout, or currency):

Paypal's CX Component Explorer
(source: Chen’s blog post)

As any author can deploy his components to the explorer, the explorer follows a distributed approach to sharing components. This contrasts with the centralized approach followed by some enterprises with a dedicated team in charge of issuing design systems and reusable components. A developer
explained on Twitter why his company favors centralized sharing:

IRIS, our design system, is our component lib. We just had a new team build a product PoC with IRiS […] in 3 weeks [mentioning that] it would have taken [them] minimum 3 months otherwise” […]
Add to that our architectural focus on microfrontends… a serious challenge for UI consistency. […]
Last thought. […] accessibility requires consistent, thoughtful HTML markup and judicious Aria enhancement. Our central team has this expertise, app teams generally do not.
[…] As for discovery we have biweekly front-end meetups to discuss in-process and completed components.

Another developer lamented that sharing at his company was hampered by the diversity of stacks in use:

Sadly we don’t share components much across my company[…] One challenge we have that you didn’t mention is different tech stacks (React, Angular, etc). Is that something you had to deal with or is everyone using React?

Chen answered that leveraging Storybook's ability to handle various UI frameworks was helping consume components across tech stacks. Chen contended that the pending release of module federation in Webpack 5 should further help.

The presented solutions from Paypal are not open-sourced at this stage. Chen mentioned being still in an exploratory phase to establish best practices for component sharing. Developers are welcome to exchange with Chen about their team’s practice of component sharing on Twitter. The full blog post contains many more technical details, explanations, and illustrations and is available on Medium.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Reusing UI Components is easy

    by Javier Paniza,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Maybe in JavaScript ecosystem everything is complicate. But in the 90s with VisualBasic or Delphi reusing UI components was plain vanilla. Indeed those components models were the inspiration for the JavaBeans specifications.

    For me the tricky thing, is creating reusable business components, like those for UI but for business concepts, like Person, Invoice, Address, etc. Have you heard about IBM San Francisco Project?

  • Re: Reusing UI Components is easy

    by Olivier Couriol,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi Javier,

    Anything reusable requires abstracting over several use cases (cf. the rule of three: blog.codinghorror.com/the-delusion-of-reuse/).

    If we talk about UIs, a simple input field has a number of variations according to use cases that makes it non-trivial to design so it is general enough to fit all the intended use cases, but customizable enough, so it fits exactly a specific use case. So an input for entering an amount of money has specific requirements linked to internationalization (right-to-left languages vs. left-to-right, position of the currency sign etc.), accessibility, etc. A controlled input field such as a slider has yet another set of requirements. Customizing styling is also a major issue that VisualBasic and Delphi probably did not have back in the days. Styling is a major reason why companies start their own design system, as styling links to brand differentiation.

    Assuming something is reusable, it then has to be discovered to be reused, which brings another set of challenges, as the article mentions. This is to say that all of this is not just linked to JavaScript the language.

    About reusable business components, this is the holy graal but that is extremely difficult. Business processes often look similar at some distance (you order, order is shipped, payment is processed etc.), and start to exhibit considerable variations (legal, local and customer variations) the closer you get. Having a single business component encapsulate all the variations means that you end up sometimes with a huge customization language which you have to learn (or design if you are the author), for each business components.

    Lampson which I quote have the thesis that only the giants survive: (www.researchgate.net/publication/226097743_Soft...)

  • Re: Reusing UI Components is easy

    by Javier Paniza,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi Bruno,

    the rule of three


    I believe in the "rule of three".

    Customizing styling is also a major issue that VisualBasic and Delphi probably did not have back in the days.<quote></quote>

    You're right, it was Windows 95 style. However, nowadays we come back to the monotonous and boring uniform style thanks to Material Design and Bootstrap.

    this is not just linked to JavaScript the language


    I'm a Java programmer, it's my duty to criticize JavaScript.

    reusable business components, this is the holy graal but that is extremely difficult


    Yes, when I was yound and unwise I tried to create reusable business components, simple ones in a controller environment (just to be shared by a few applications), without success. Now, that I'm old and unwise I still think that creating reusable business component is possible.

  • IRIS correction

    by Michael Robertson,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hey Bruno good piece. I’m the design system director at FICO and it was my comment thread with Dong that you referenced. Our internal design system is called IRIS but it’s not the one you linked to for the record.

    ::Michael Robertson (@ngIRISmr)

  • Re: IRIS correction

    by Olivier Couriol,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi Michael. Apologies for the mistake. Do you have an official link that you can share? In the meanwhile, I will remove the erroneous link.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT