A TDS component does not do what I need. What do I do?
The design system must strike a balance between flexibility and consistency. If components are overly flexible they become unwieldy and lose their outcome of consistency. But, if they are too rigid they become less useful and frustrating.
If your design shows a component being used in a way that does not match what is available in code, it may be either a mistake in the design, or a feature that has not yet been coded.
Either way, let us know about it so that we can work with you on the appropriate solution.
How is TDS versioned?
As of March 2018, TDS switched to "split components" and each TDS component is an npm package that adheres to Semantic Versioning to make it easier for consumers to manage upgrades across independent components.
Due to the subjectivity of versioning front-end components, this is the guide we use:
- Breaking changes are removals of features such as props, changes that affect the box model, or dramatic changes in branding or appearance
- Minor changes are new features, animations, props, or visual options
- Patches are defect fixes that do not remove features, alter pixel dimensions related to the box model, nor add new features. If an intended feature was not working in a previous release, changing that feature to match the original design counts as a patch even if it affects the box model
Learn more by reading the TELUS Design Platform roadmap.
What browsers does TDS support?
- Microsoft Edge
- Internet Explorer: 11
Do I need any polyfills?
TDS often uses non-invasive ponyfills (a polyfill that does not modify built-in APIs) if it uses a browser API that is not widely supported natively.
What global styles does TDS set on the page?
The majority of TDS styles are component styles that have been generated by our build tooling to prevent conflicts with application styles. However, there are a small amount of page level styles (bundled as @tds/core-css-reset) to establish a common baseline.
How do I test with TDS components?
Treat TDS as you would any other third party dependency. Focus on testing the UI and business logic of your components, without relying on the internals of TDS components.
All TDS components accept most standard HTML attributes, which are helpful with testing. We recommend giving TDS components either
data-testid attributes when you need to find or interact with them in tests.
What if I'm not using the Reference Architecture (RA)?
Technically, TDS is a library of React components that are bundled as transpiled ES6 modules that can be used outside of the RA. However, it is strongly encouraged to use it together with the RA (TELUS digital Platform) to easily implement all of the standards that TELUS web properties need to follow and are enforced by DRB.