Future of Clarity Angular

[dorthrithil]

I see that you are putting a lot of work in Clarity core which is awesome. At the same time I see that first bug reports are getting closed as wontfix because of the move to core (e.g. #5299).
In a blog post I read that core will not fully include any components that require complex datamanagement like the wizard and the datagrid in the way we're used from Clarity angular.

Does this move to framework independence mean that you will no longer maintain components like the angular wizard or datagrid and developers have to build their own core component wrappers for this?
If so, a complete list of future deprecations or no longer maintained components would help to evaluate my team if we will stick with Clarity and take the overhead of writing own wrappers or if it's better to switch to some other system.

I really really like the quality and look and feel of Clarity and the fast and positive response to community requests. So it would be awesome if you keep developing Angular components on top of the core components. :)

[bbogdanov]

@gnomeontherun

[gnomeontherun]

Hi @dorthrithil, I'm finishing up a blog post in the next couple days to describe some of these things. Since that will cover most of your questions above, I'll just give a quick response for the immediate moment.

1. Clarity Core will eventually have (almost) all of the same components that Clarity Angular has. We are adding features, addressing some bugs, and meeting accessibility requirements as we rebuild the components. There are some minor differences, but they are very much still the same Clarity style. The main exception is we aren't planning to build a Core Sidenav since we will build the Core Vertical Nav.
2. For more complex components (like Datagrid) you should expect to have far more control over how it behaves but some of the built-in stateful behaviors (like client side sorting) won't be available with Core. Details about the specifics will be available as we find out the limits of possibilities, and we are also considering what kinds of wrappers might make sense or not as we get closer to those. Basically, web components need to be as stateless as possible for maximum compatibility and flexibility.
3. We are going to stop adding enhancements to Clarity Angular and only put enhancements into Clarity Core (like Add support for [clrLoading] for Wizard buttons #5299 indicates) starting with v5 (beta is out). We want to stabilize Clarity Angular for the long term so that applications can depend on it as long as they want or need. Clarity Angular will get bugfixes and updates for Angular releases, but new features will go into Clarity Core components which can be adopted by any project.

Clarity Angular has some features that are not going to be identical in Clarity Core, particularly where Clarity Angular maintains some internal state for an application. We are working on adoption support that will help bridge the gap so you aren't left with questions how to update your applications when more complex components are available (like Datagrid or Tree View). In some discussions with teams the changes are going to enable a greater degree of control and minimize some frustrations with the existing behaviors when applications try to use components in new ways, so overall this should be a big improvement.

At the moment, we are not planning to build Angular components on top of Clarity Core. We tried earlier this year and it turned out to cause more problems than it solved. It also was slower because we were writing shim layers between Clarity Angular and Clarity Core which were adding to the change detection cycles and increased the surface area for bugs and lifecycle issues. Using Clarity Core directly is much faster and less code to maintain.

I hope this helps clarify and we'll be adding more to our blog in the next couple months as this is not an immediate change but an evolution of the design system that will take some time. Our goal is to support teams in using Clarity Angular as long as they need and then adopting the Clarity Core components (see my upcoming blog post) on their timeline to get the new capabilities and improvements through Core.

[dorthrithil]

Thanks a lot for your detailed answer! This helps a lot.

[gnomeontherun]

Blog post is up! https://medium.com/claritydesignsystem/level-up-your-application-by-adopting-clarity-core-8a5f3f863139

[mcosta74]

@gnomeontherun So, if I understood correctly the guideline for writing an Angular app that uses Clarity is to:

• prefer Clarity Core components
• fallback to Clarity Angular components for the ones not yet implemented in Core

Then I have some questions

• may I use Core Layouts and Design Tokens also in apps that use Clarity Angular ?
• are you going to NOT accept anymore new Angular components ? Feature proposal only for Core?

[gnomeontherun]

Everything in Clarity Core can be used in an existing Clarity Angular project. There are some things that may conflict (because the Clarity UI/Angular CSS has a lot of styles that are generic) so we're working on how to help block that from happening, but otherwise things like layouts and design tokens are agnostic to Angular and we'd love to see people using them.

As far as new Angular components, the answer is we're not investing in additional Clarity Angular components, only to replace them a few months later. We'd like to see all external contributions also be for Core, but we need to enhance our guidelines and guidance before we're ready to accept a lot of larger contributions.

[mcosta74]

Thanks for the answer.

Time to start learning Lit-Element 👍