Whether it is for web or app, every component should be considered mobile first and degrade to desktop. Components should take advantage of the platform.
All Backpack components should work in multiple areas and situations, not just in the context of one screen.
Reuse over reinvent
For any new component, we will look to the open source community for inspiration. If they meet our requirements, we will directly use them.
Screen readers, keyboard navigation and other assistive technologies are important as we look to support all kinds of travellers. All Skyscanner products should be accessible by everyone no matter their disability or situation. See our Accessibility guide for developers (other guides coming soon) for best practices.
All components support RTL (also known as bidirectional languages).
Each component should be fully documented, showing each configuration together with explanations where suitable. Additionally the component's readme and available props should be shown. See our guide on writing style for best practices for writing documentation.
Declarative UI Components
Backpack components must support Declarative UI.
With the new Design Systems (SwiftUI and Jetpack Compose) there's a need for defining how are we tackling the creation and maintenance of reusable Backpack Components.
- Create the component in new system only
- Create wrapper in the old system if there's a need for that component to be used in the old system
Creating Declarative UI version of an existing component
Create the component using the new Declarative Framework. If the complexity of the component is too high, then Wrapping the old component with a Declarative API is recommended.
Why not just wrapping everything?
There is a Risk involved in wrapping components, like introducing bugs while mixing new and old systems as they may require data and delegation mapping.