RFC-81: Upcoming changes to Iconography

General Request for Comments (RFC)
, , , , ,
2

Hi @AkshaySaini,

please understand my comments with the knowledge that I’m actually someone who cares deeply about consistency and is usually on the forefront when it comes to adopting new UI things, to match the Atlassian design system well (e.g. dark mode in all our apps, etc.).

This proposal however, is not something we are going to do, I’m afraid, as it basically creates a huge overhead in terms of development for us, only to achieve consistency for a few months (if at all). We are not currently using codemods in any capacity, because the size of the codebase currently does not justify the investment, so for us, all of this means adjusting all icons manually.

I just checked, and we currently have 650 uses of Atlaskit icons at the moment. I have a hard time imaging a solution that would be more effort for us, than what you are proposing, this is by far the worst outcome - sorry to be so blunt.

A way better solution would’ve been you transparently switching the old implementation to use the migration components internally and allow us to use the migration by just upgrading the package.

Example:

// Current implenmentation in our code (@atlaskit/icon: ^22.24.1)
import ChevronDownIcon from '@atlaskit/icon/glyph/chevron-down';

...
<ChevronDownIcon label="Login" size="small" />

Now, could you not release a new major icon package version which just switches the internal exports to the migration one? E.g. in @atlaskit/icon/glyph/chevron-down.ts you do:

// Code in @atlaskit/icon/glyph/chevron-down.ts
import ChevronDownIconMigr from "@atlaskit/icon/core/migration/down--chevron-down";

const migratedIcon = props => {
return <ChevronDownIconMigr 
              LEGACY_size={props.size}
              LEGACY_primaryColor={props.primaryColor
              LEGACY_secondaryColor={props.secondaryColor}
              LEGACY_margin={props.margin}
              ...props
     />;
}

export default migratedIcon;

And release this as a new major icon version? Or as a separate package (@atlaskit/icon-new)? Why does every single consumer need to do this mapping and then remove it a month later again? This is what breaking/major update in packages are meant for. If there is no simple 1:1 mapping, you could remove these icons and we could go ahead and fix them manually, but this would be still at least factor 10 less effort than adjust everything.

Reiterating: If this proposal goes through as is, we will not use the migration components but switch to the new icons only at some point, accepting there will be inconsistencies along the way - the effort to migrate everything twice is just not justifiable for us, considering all the other initiatives (Forge etc) we need to be tackling right now (see Taking the Ecosystem Forward: An Update on the Future of Connect).

If your aim is indeed widespread consistency, also in the in-between rollout phase, I would strongly suggest reconsidering the approach, I have a hard time imaging that this will see the broad adoption you are aiming for (which a simple package update would make much easier).

Thanks for the detailed write-up!

Best
Tobi

13 Likes