Authentically mobile
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.
Holistically considered
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.
Accessible
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.
RTL supported
All components support RTL (also known as bidirectional languages).
Well documented
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
What
Backpack components must support Declarative UI.
Why
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.
How
New 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.