Pando questions answered
Key terms
Headless Styles (deprecated) - A component-less library created to allow building a fully custom component without the need of a Component Library. This library has been deprecated in favor of a more flexible solution via “Recipes” in the forthcoming v1 release of Pando.
Why do we need a new version of the Pluralsight Design System (PSDS)?
Classic PSDS was conceived of when Pluralsight was a single product company. Over time, some key issues with Classic PSDS became clear, including:
- The system was too restrictive
- Props needed were not exposed at the component level (not flexible)
- Version updates happened too frequently (hard to keep up)
- Constantly shipping breaking changes - the system was built extremely tightly coupled, meaning there was no way to update a single component style without causing global impact on all 65 components, including unit tests
- Not all components used design tokens. Some used variables, defeating the purpose of design tokens or a system in general
- Dependencies upon dependencies
- Not themable. Difficult to scale
- Classic was never built with full accessibility in mind
- Many teams 10+ versions behind
Ultimately, updating Classic PSDS would not have benefitted enough consuming teams to make the effort worthwhile.
How does Pando solve the issues from Classic PSDS?
Pando was built with long-term scalability and maintainability in mind from the beginning. All of the packages work in a compound way (they can function independently or with each other). Additionally, Pando uses the standard approach to
Because of key differences in the design of the Pando system, consumers of the system will get full flexibility to use the foundational system and extend it for their own context, and own their integration (this solves the Classic PSDS issues of being too restrictive and not exposing props at the component level).
How is Pando different from Classic?
Pando is all about flexibility and putting control in the hands of the consumers of the system. We’ll provide foundational styles, accessibility, components, hooks, and even helper functions and the user will have enough tools to easily build custom components when necessary.
Key points to understand about the differences between Classic PSDS and Pando
| Classic PSDS | Pando |
60+ packages, multiple nested dependencies and reliance on third-party libraries. | Three packages (React, Icons, and Panda-Preset) combined with a CLI that manages setting up and keeping the system up to date in your local project. |
| Shipped breaking changes with every release | Uses the standard approach to
|
Built with React. Not able to support other technologies, the www site or PS mobile apps | JSX agnostic, meaning it supports any library that uses JSX (i.e. React, Svelte, Vue, etc.) |
Component library; very restrictive, designed for narrow use cases, needed props not exposed at component level. | An infrastructure-level library that provides both components and/or CSS-in-JS helpers when you need to fully customize. |
| Not themable | Built for multi-theming that utilizes two different modes (i.e. light/dark). This means Pando supports creating multiple themes (i.e. inkyBlue, high-contrast, etc.) that each have a light/dark mode. |
| Never designed for full accessibility | Designed to be fully accessible out of the box. |
I’ve heard about the v1 release of Pando. What’s that and when is it happening?
Pando v1 will be a stable, production-ready release. Pando v1 will include the React component library, Panda Preset, Design tokens, and Icons.
Our original goal was by the EOY 2023. However, since the announcement of React 19 features and NextJS basically taking over the project - that has delayed our original goals. This is due to the introduction of server components and a general overall change in the React design that will affect all React users (including Library maintainers like Pando!). This is a positive change though for the customer experience in terms of performance and code quality/reliability for developers.
Thus, to ensure that any team will have compatibility with Pando (no matter the React version) we needed to change and upgrade how we approached our libraries and even testing our components in a dev sandbox. Here is a high-level look at the changes we have progressed to in order to successfully be compatible “out of the box” for React 19:
- We share the same build process as the TanStack libs which now also support both legacy and modern Node environments
- We now use Next14+ for our dev sandbox to validate that our APIs work seamlessly in an advanced React 19 app using Sever Component features
- We now include integration level testing via our sandbox to ensure we are covering all the bases (as much as we can within the realms we are allowed/have tools for in our company)
Back to the question at hand: due to the shift in React, development takes a little longer than it did before. This is because we now need to ensure React 19 compatibility in our sandbox. We also need to include that additional level of testing on top of the API development. This means that realistically, the “complete” v1 library should be done sometime in early 2024.
What is the problem Pando v1 will solve?
Our biggest goal we will solve with the v1 Pando update is simply to become an accelerator for teams.
But what does this really mean? Ultimately, any tool we use either helps accelerate or hinder our day to day productivity. Thanks to everyone who has become early adopters of the pre-releases of Pando (current), we have learned of some key areas where we could improve our library to achieve that goal.
Thus, with v1, Pando will be:
- Easier to adopt, install, or maintain
- Allow our library to be incrementally adopted based on the level of comfort for each team
- Provide even more flexibility to teams (there are literally no limits in v1)
We’ll do all of this while still delivering a foundational style-infrastructure for the company to have a consistent team experience without sacrificing the customer experience (i.e. our actual customers will benefit with a higher performance rendering outcome in their browsers from Pando adoption).
What’s happening to headless-styles in Pando v1?
We have successfully started the process of deprecating the headless-styles library, while still offering the same features and more with our
What’s happening to design-tokens in Pando v1?
design-tokens will continue to exist in v1, supplemented by additional tokens. The tokens will be used in the Panda-preset to provide a more flexible and scalable solution for styling.
With Pando v1:
- headless style functions are now delivered in the preset via “recipes”
Additionally, the Pando panda-preset will now also include the tokens.
Pando Architecture
The following sections describe the overall design of Pando and how it contributes to the usage for developers.
—
Pando panda-preset → Panda Preset that drives the Pando custom library options available to developers
React Component Library → Additional component library of pre-built solutions of everything included in the Pando Figma UI Kit in addition to extra utility components and hooks. This will also expose static css so that components can be used out of the box without additional configuration.
Icons → Component library for displaying Icons
Design Tokens → Tokens used in the Panda Preset
Panda CSS (how things are styled)
Panda is compatible with and also creates initial components for any JSX-related library (i.e. React, Svelte, Vue, etc.). This means developers can either use helper functions or JSX components within their projects.
Pando Preset (custom Pando settings)
The Pando preset adds everything you need for making styling easy to use and fully extendable with Panda CSS. In the preset we include everything from:
- Global CSS
- Custom Conditions
- Custom Patterns
- Custom Fonts
- Custom Utilities
- Custom theme options - keyframes, semantic tokens, fonts, text styles, z-index layers
React Component Library (fully built components)
This library contains pre-built, composable, accessible, and fully extendable React components of everything provided in the Pando Figma UI Kit. Additionally, it provides some custom utility components that mimic popular libraries (i.e Show, For, etc.) and custom hooks (i.e. useTheme, etc.).
Icons (fully built components)
This library contains all the icons that are provided by Pando as React components, Raw SVG, or strings.
What does that mean for how my team uses the Pando Design System?
Because Pando is JSX library-agnostic, it means that we’re able to provide support to other teams that are not using React, for the first time. Over time, this will allow us to keep the Brand more unified and drastically cut down the dead time engineers need to take to refactor everything to update to a new evolution of the Pluralsight Brand.
I’ve heard about Pando and new Pluralsight branding. What’s up?
As you probably are aware, the
Work began on Pando as the Brand work was kicking off at the end of 2021. So, Pando is literally built on the new Pluralsight Brand and the best way to update–and stay updated with–the Brand.
What is the level of effort to migrate to Pando?
It’s difficult for us to estimate this since every team uses a different amount of UI components. For example, Worklog in Flow only uses a few Buttons, whereas a Settings page might use several inputs, buttons, checkboxes, radios, icons, links, etc.. Level of effort will ultimately depend on a few things:
amount of components used
number of instances of those components, and how varied each instance is
engineering experience/speed on the team
Ultimately, level of effort = low-mid depending on the above three factors.
To get an idea of the level of effort involved, we recommend using a time box (e.g. one day) to begin updating a single feature on a page and seeing how far you get. We think you will learn a lot in a short amount of time and that doing so will remove a lot of the uncertainty which can cause predictions around the level of effort to significantly increase.
To learn about migrating from Classic PSDS and to gain clarity on what the corresponding level of effort should be for your team, visit our guides:
Early success story: the Hawkeye team in Skills spent 3 weeks (balanced with other work that came in) at the beginning of 2023 migrating everything from Classic PSDS to Pando, including building their own components.
Note: If your team has low usage of Classic PSDS, it does not immediately mean that level of effort is low. For example, if you have 10 different internal input components, you will need to either update all of those to use Pando, or you will have to modify them all to align with the new brand. We recommend updating them all to Pando (and consolidating to a single multi-purpose component where feasible).
Is Pando meant to be used with a third party component library (such as MUI or Chakra)?
We are recommending that only teams that are already using 3rd party migrate to Pando components to ensure consistency and deliver the best user experience to our customers.
The golden path that will provide the best customer experience and long-term engineering experience is to use the CLI and remove any libraries that Pando does not use (for UI).
We do not recommend that teams default to combining this with 3rd party libraries just because they want to use a 3rd party library. Doing so will dramatically increase the level of effort to migrate and will create long-term issues by using additional libraries we don’t own.
As for fragmentation in the experience, we recommend creating agreements around standardization of the approach to extending Pando (which is focused on foundational styles and a11y) to avoid divergent frontend solutions.
Can we adopt the new system in a piecemeal fashion or is it an all-or-nothing update?
Incremental adoption is possible and encouraged! The level of effort will vary from team to team, depending on code health, skill level, etc. so there’s no way for us to accurately predict that without knowledge of each individual code base. The Pando team is available to help assess codebases, help teams plan for adoption and get started with migration.
We need to be able to move fast building UIs, and we use React. We heard that Pando is not built with React. How does Pando help us do that?
Pando uses React. If you hear anything otherwise - it is not true.
Are your package compatible with React 19?
Yes! We build our libraries using React 19 concurrent mode and server components during development to ensure our products will be compatible out the door so you can keep moving your apps forward to have the best user experiences.
Why didn’t we just update Classic PSDS?
Unfortunately, this answer is more complex than it may seem. There is ultimately a “problematic pyramid” of issues with updating Classic PSDS with the new brand:
Foundational issues with Classic PSDS
- Design: The new brand is centered around a theme (57 design-tokens). Classic PSDS was never designed with a theme and ultimately had around 160 tokens total.
- Engineering: Classic PSDS was built extremely tightly coupled, which means there is no way to update a single component style without causing a global impact on all 65 components (this also includes unit tests).
- Not all components use design tokens. Some use static variables. This inconsistency ultimately defeats the purpose of the 160 original tokens and doubles the effort to find/update each component.
- Classic PSDS was never built with full accessibility in mind. This means that it also requires a fundamental refactor for all spacing values to accommodate users that require larger text.
- Pando and Classic PSDS are not 1:1 replacements. Both have elements the other doesn’t due to new branding updates.
Core issues with Classic PSDS
- Not all teams use Classic due to different reasons. Some Product teams have abandoned Classic PSDS to make their own libraries.
- Not every team using Classic PSDS is on the same version. Unfortunately, some teams are more than 10 versions behind the latest.
- The original Classic PSDS engineering team shipped breaking changes with every release (this is extremely problematic for the teams who are not on the latest versions).
Apex issues with Classic PSDS
- By releasing a style update on Classic PSDS, we inevitably cause more stress and anxiety for the teams who are not using the latest versions. This will compound the tech-debt for these teams, due to the breaking changes shipped with prior versions.
- It’s important to note that some teams are stuck in an old version due to foundational issues that naturally occur in Legacy code, meaning that upgrading to a newer version inevitably breaks the product UI in a way that is hard to debug.
With all the points in mind, upgrading Classic only benefits a small fraction of the teams who are using it and are on the latest versions (estimated around 1%).
How does Pando solve these issues?
Pando was built with long-term scalability and maintainability in mind from the beginning. All of the packages work in a compound way (they can function independently or with each other). Additionally, Pando uses the standard approach to
Where can we go for answers, or with more questions?
Within Pluralsight’s Slack, visit #pando-design-system and #pando-help.