Taiga UI: 2023 Results
Today is Christmas, making it a perfect time to summarize the fruits of our labor over the year. In 2023, Taiga UI project had more than fifty releases, more than two thousand merged PRs and over five hundred closed issues.
Taiga UI is a powerful set of components for Angular, which is used in dozens of Tinkoff’s products. The project has been developed in Open Source for many years, gaining an audience worldwide.
In the article, I will continue our annual habit and briefly unpack the overall achievements related to Taiga UI over the past year.
More than 3 years in Open Source
For many years we’ve been developing our products publicly in Open Source. It’s important for us that users can always explore the source code and make their own amendments to enhance Taiga UI. In 2023, more than 20 external contributors submitted PRs of various complexity levels: from minor documentation adjustments to fixing serious bugs or even whole large features, such as BreakpointService or declarative dialogue routing.
Over the span of three years in Open Source, the number of contributors has exceeded the milestone of one hundred and fifty people! We can’t emphasize enough how much we value their contributions and welcome any improvements ❤️
This summer, a significant change took place in the history of Taiga UI. It has turned into something more than just a UI Kit. Taiga UI is now part of a whole family of products united under the common name of Taiga Family.
We have relocated to a separate GitHub organization where we have assembled the best technical solutions used for developing Taiga UI, including ng‑web‑apis, maskito, ng‑polymorpheus, ng‑morph, ng‑event‑plugins, and others. Among these, you will surely discover something useful for your Angular application or library. For more detailed information about each product, my colleague has written the following article:
We are pleased to see the growing public awareness of Taiga UI. In 2023, we gained 17% more stars on GitHub, and the number of downloads via npm exceeded 350,000. By comparison, in 2022, this number was slightly less than 200,000.
New mask for text fields
As 2022 came to a close, a remarkable event set a significant task for us in 2023. For years, the task of seeking an alternative to the text field masking library had been pending in the Taiga UI backlog. After many rounds of research and discussion, our team devised our own dedicated library for this task — Maskito.
At the beginning of this summer, the first stable major release was published. By that time, Maskito had expanded beyond being a single library to a full-fledged collection of libraries. The new development included the framework-agnostic package @maskito/core (a standalone and already sufficient package for initiating text field masking), the optional package @maskito/kit with a set of ready-to-use and configurable masks, and separate packages for popular JavaScript frameworks like React, Angular, and Vue.
If you’re interested in learning more about the development history of Maskito and seeing all its advantages in action, I’ve written about it before. Feel free to read more by visiting:
We were uncertain until the last moment whether we had managed to create a flexible and user-friendly tool that would avoid the errors of its forerunners. The positive reaction from the community allayed our fears.
On June 21st, the widely-used framework Ionic made an announcement naming Maskito as the recommended masking solution in its components. And now, on the Ionic documentation page, you can always find the guide on how to use Maskito within your Ionic application.
The community expressed interest in the new product, and by the year’s end, the cumulative number of downloads on npm had exceeded 300,000. It was particularly encouraging to see that even large enterprises had adopted Maskito!
We have entirely migrated all the masked text fields from the Taiga UI library to the new mask, solving numerous legacy issues. However, we are not resting on our laurels! Maskito still has areas to grow, and we aim to evolve it further. Stay tuned for the second major release, which is just around the corner!
InputPhoneInternational and @maskito/phone
We have an amazing component that can be tweaked endlessly. No matter how much effort we put in or how many hours we dedicate to its design, adjustments will emerge sooner or later. It’s name is InputPhoneInternational.
The issue here isn’t about our laziness or shifting our focus elsewhere. It’s because this component is a masked text field for entering international phone numbers, and the patterns for international phone numbers have a history of changing and expanding over time.
For a long time, we stored the masks for the phone number formats of different countries as a constant in our repository. As expected, updating this constant wasn’t always done promptly, which caused quite a bit of trouble. Luckily, the primary advantage of Open Source came to our rescue — bug reports from the community. A significant number of issues like #3102 were raised.
We weren’t fond of constantly having to update the formats for phone numbers and wanted to shift the responsibility onto someone else. We found the perfect candidate — Google. The company has a library, libphonenumber, which contains the patterns for phone numbers from all countries around the world, and they’re always up-to-date! We realized immediately that it was exactly what we needed.
Sadly, the process turned out to be quite complicated. Before we could begin using it, we had to deal with a huge amount of data — the format was not at all suited for easily utilizing the data to construct masks for text fields. Consequently, we developed an additional package, @maskito/phone, which built upon Maskito and the libphonenumber-js package to offer a convenient API. It provides you with the opportunity to create a masked text field for a phone number from any country in just a couple of lines.
In September 2023, the development of the package was completed, and we made its first release. The package turned out to be convenient and flexible to use. For example, a library user can regulate the size of the bundle by choosing different sets of metadata (max, min, or mobile). You can read more about all the features of the new package in our documentation.
Very soon, in the Taiga UI 4.0.0 release, the new package @maskito/phone will be used inside InputPhoneInternational component, permanently eliminating the concerns about updating international phone numbers. Our users will simply need to update the version of the libphonenumber-js library.
Native mobile controls
Towards the end of 2022, we decided to implement the ability to use the native mobile controls in some of our input components. For instance, native dropdown lists or calendars.
The first such feature introduced for the Select component in October 2022. And by 2023, this feature was released across a whole list of our components: MultiSelect, InputDate, InputTime, InputDateTime, InputMonth. The public API of these new features may differ among components, but the core principle remains the same: the desktop version of the component uses stylized Taiga controls, while the mobile version invokes the native system tools. Different mobile platforms will style the controls according to their own design.
To demonstrate what the new feature looks like in practice, take a look at this example. If you open it on a desktop, you’ll see that the InputDate component, when focused, opens up a stylized Taiga calendar.
However, if you open the same example on an actual mobile device, clicking on the calendar icon will bring up the device’s native calendar, styled according to the operating system of the device.
Native controls have a number of advantages that custom analogs simply can’t match, no matter the effort. For example, native calendars and dropdown lists can extend beyond the boundaries of the browser window, which can be quite useful on smaller mobile devices. Moreover, such native controls will automatically be styled according to different operating systems, which means they integrate harmoniously with the device’s overall design and look familiar to the user.
If we set aside all the technical advantages, there is another meaningful point regarding the significance of this feature. In product development, there’s a commonly used “hack” in which a business, as a stopgap measure, postpones the development of a full-fledged iOS or Android application for their product; instead, they leverage their existing web application version, packaging it inside a native mobile app shell. This article will not delve into the merits or drawbacks of WebView. It’s important to note that smart use of this approach requires that the web version of a site should effectively mimic a native mobile application in both behavior and appearance. The use of native mobile controls can be a good solution within such a strategy, even though the component may retain its unique behavior on desktop platforms.
The instructions for implementing the feature are divided into two groups:
- For text fields used for entering dates, times, and months, this is done through Dependency Injection configuration:
import {tuiInputDateOptionsProvider} from '@taiga-ui/kit';
// ...
providers: [tuiInputDateOptionsProvider({nativePicker: true})]2. For components used for selecting items from a dropdown list, you simply need to place the native <select /> tag inside the already familiar <tui‑select /> or <tui‑multi‑select /> tags, and enhance it with the tuiSelect attribute. Following that, the codebase will automatically handle all the necessary magic.
<tui-select [formControl]="control">
Character
<select
tuiSelect
[items]="items"
></select>
</tui-select>Editor: more features
For an extended period, the Editor component was developed within a monorepository along with other Taiga UI packages and had only a single page of documentation. But over time, this component began to feel cramped. Moreover, it no longer seemed right to call our vast wysiwyg just a “component.” The time has come for it to leave the parent nest and embark on a journey of its own…
Since June, the Editor has been residing in a separate repository, featuring its own distinct documentation and versioning system independent from the other Taiga packages. It is now officially known as the @tinkoff/tui‑editor package.
In 2023, our editor has been equipped with new and interesting features: it now supports native audio/video tags, and inside the editor you can embed a full YouTube player or even an iframe that can be adjusted in width with any content inside. And, of course, we don’t intend to stop here; we plan to continue enhancing the editor even further!
More components and new @taiga-ui/experimental
Until recently, in the development of Taiga UI, we aimed to focus on constructing atomic components, making a point of avoiding complex organisms. But in today’s world, the demand for web applications has skyrocketed, particularly for their mobile versions or even modern PWAs. Creating high-quality web applications rapidly has become extremely important. In light of these new trends, we have deviated from our previous rules and have begun to prepare ready-to-use popular mini “organisms” (or, as we call them within our team, “layout”-components).
This led to the creation of the TabBar and AppBar components, which embody the popular design pattern used in mobile applications for navigation between sections.
We also developed the BlockStatus component, which simplifies the creation of status pages. For instance, it’s useful for developing the infamous 404 page, present in almost every application. In the autumn of 2023, the @taiga-ui/experimental package was enriched with a variety of other useful layout components: Card, Cell, Title, and Surface.
The
@taiga-ui/experimentalpackage contains components that do not yet have a strictly defined public API; it can be changed, disregarding semantic versioning rules. In the upcoming major release, these components will be moved to stable packages, their public API will be finalized, and they will start to follow semantic versioning.
The new layout components in @taiga-ui/experimental are not the sole innovations within this package. It contains a plethora of updated and refined versions of existing components, along with some completely new features.
For example, take the updated Checkbox, Radio and Toggle components. The new versions have become attribute components and now can be directly used with native <input /> elements. In the next major release, the <tui-checkbox /> tag will be eliminated from the templates and will be replaced by <input tuiCheckbox type="checkbox" />. This means that the new component version will provide full access to all native input’s attributes, resulting in a lighter component and cleaner code structure. This achievement is thanks to the CSS mask property! Additionally, the new versions of the components can be optionally styled with just a single line of code to visually resemble the native iOS or Android system controls.
The Sensitive component has been introduced, which hides part of the content from the user’s view. For instance, in Tinkoff applications, such a feature is actively used to allow users to conceal their sensitive data — like balance amounts or bank account information — when recording their screen or showing something personally to their friends. The secret to the component’s success lies once again in the use of a CSS mask.
Using an ellipsis at the end is a common method to indicate that text has been truncated. If you’re looking for an alternative, there’s a new option — Fade component. Guess how this effect is achieved? Correct, once again, the implementation relies on the familiar CSS mask!
Are you weary of the constant mentions of CSS masks? This is only the tip of the iceberg! In 2023, this feature has become one of the key contributors to the @taiga-ui/experimental package. With just this single property, we’ve managed to refresh the ProgressSegmented component’s version by applying a mask on top of the ProgressBar component.
Delving deeply into the technical details of implementing so many elements with the CSS mask requires a separate article. If our team has the strength and time, and the readers show interest, then we will certainly prepare it, including all the details!
The CSS-mask has also been influential in the revamped version of the Button component. A redesign of the architecture for the new buttons has streamlined the component’s codebase without compromising on its past functionality.
The latest addition, but certainly not the least important, is the new component for handling icons — Icon. It renders icons through a CSS mask, introducing new opportunities:
- The possibility to store icons on a CDN and display them without any DOM manipulation or the need for a sanitizer;
- A more straightforward approach to icon scaling. Just merely change the dimensions of the host component — the icon automatically scales, and the use of the
vector‑effect="non‑scaling‑stroke"property allows for this scaling without compromising detail or causing unwanted changes in line thickness. - The browser automatically implements icon caching.
All of these improvements allow us to “retire” a significant part of the codebase, making the work with Taiga UI much more straightforward.
The upcoming release 4.0.0, Taiga Renaissance?
It has been over a year since the last major release of Taiga UI. We have deliberately avoided updating the Angular version for an extended period to preserve compatibility with your projects that rely on older versions of the framework. We refrained from making breaking changes for a long time, allowing you to seamlessly upgrade to the latest versions of our libraries. And for an extended period, we’ve continued to support some exceedingly outdated browsers.
Maintaining this approach is challenging and at times it can be counterproductive to the quality of our libraries. For this reason, the Taiga team is actively discussing the proposition of increasing the frequency of major releases (small ones every six months to a year, instead of massive releases every one and a half years) and the aspiration to match the support for the minimum version of Angular in our libraries to the same cycles promised by the framework’s core team.
As we look toward the beginning of 2024, a new fourth major release of Taiga is on the horizon. We plan to update the minimum supported browser versions, embracing more contemporary browser features, which in turn will make our libraries lighter and more reliable. We will upgrade to Angular version 15, which at last will grant us the opportunity to implement standalone components and the Directive Composition API. We will finalize the public API of our new experimental components and incorporate them into other stable packages.
You can start preparing for the forthcoming release right now: update Angular in your application to at least version 15+, and update Taiga to the latest release. Then, our schematics will handle a significant part of the concerns for you!
If all preparations are already complete, then it’s the perfect time to make yourself a cup of cocoa with marshmallows, sit in a comfy chair opposite a decorated Christmas tree, and fully immerse in the festive holiday spirit. Taiga UI team wishes everyone a Merry Christmas!
