DEV Community: Shivam

Stop micromanaging pixels | Build UI that understands where it lives.

Shivam — Fri, 11 Jul 2025 11:22:49 +0000

Most modern UI workflows are still obsessed with primitives:

Button

Card

Modal

Sidebar

Then we duct-tape them together with padding, spacing, radius, colors , hoping it feels cohesive.

But here's the truth:
Good UI isn't built with components. It's built with intent.

You don’t just need a .
You need a “Confirm” button in a modal.
Or a “Back” button in a sidebar.
Or a “CTA” on a landing page.

These aren’t just variants, they are contextual semantics. And no amount of Tailwind classes or design tokens will magically encode that meaning.

I got tired of pixel micromanagement and meaningless abstraction.
So I built a tiny experiment:
👉 semantic-ui-forge.lovable.app

It’s not a product. It’s not even a library.
It’s a design system manifesto, expressed in code.

Think of it as:

A way to see how the same element behaves differently across contexts

A minimal testbed for semantic decisions (e.g. what should a sidebar button look like by default?)

A call to stop building dumb primitives and start encoding intent

If you're a frontend dev who's been feeling this but didn't know how to name it, check it out.

Let’s stop pushing pixels and start communicating purpose.

Angular's DI can make your components smarter

Shivam — Sun, 24 Apr 2022 15:42:59 +0000

Angular's built in Dependency Injection is quite powerful and today we are going to see how we can use it to make our components smart(er).

Let's talk about button component

<app-button  
accent=" primary | danger | success | ... "
size =" small | medium | large | cta | ... "
icon = "[ ... ]"
iconSize = "sm | md | lg | ..."
label = "[ ... ]"
translate = " true | false "
ripple = " true | false "
tooltip = "true | false"
...
 >
</app-button>

Here, we can see that the button component provides different configuration option so that we could use it to cover different use cases.

Providing all these input's all the time could get cumbersome which could also lead to inconsistencies.

In order to solve this problem, we first have to find out all the places in our application where button could be placed.

for example

Place	Button Size	Icon Size	Show Tool Tip	Icon Only
App Header	Large	lg	false	false
Card Header	Medium	md	false	false
Table Row	sm	sm	true	true

Once we have clear idea of how and where our button is going to be used then we can create Angular's Injection Token for all the inputs where the value could be deduced from the context.

 const BUTTON_SIZE_HINT_TOKEN = new InjectionToken<
    small | medium | large | cta | ... 
>('Button size hint token', {
    providedIn: 'root',
    factory: () => 'medium' // default value
});

 const BUTTON_ICON_HINT_TOKEN = new InjectionToken<
    lg | md | sm | hide | ... 
>('Button size hint token', {
    providedIn: 'root',
    factory: () => 'md' // default value
});

const BUTTON_TOOLTIP_HINT_TOKEN = new InjectionToken<
    boolean
>('Button size hint token', {
    providedIn: 'root',
    factory: () => false // default value
});

...

After creating these tokens, we have to use it in the button component.

// button.component.ts
// ...
// ... code ommited for brevity


 constructor(
    @Inject(BUTTON_SIZE_HINT_TOKEN)
    private  buttonSize:   small | medium | large | cta | ... ,

    @Inject(BUTTON_ICON_HINT_TOKEN)
    private iconSize: lg | md | sm | hide | ...,

    @Inject(BUTTON_TOOLTIP_HINT_TOKEN)
    private showToolTip: boolean,

// ... other dependecies
    ){}

Here, we can use these hints to the set the default value in the button component.

The next step would be to provide these hints in the places where the button is going to be used.

@Component({
    selector: 'app-page-header',
    templateUrl: './template-file.html',
    providers: [
        {
            provide: BUTTON_SIZE_HINT_TOKEN,
            useValue: 'large'
        },
        {
            provide: BUTTON_ICON_HINT_TOKEN,
            useValue: 'lg'
        },
        {
            provide: BUTTON_TOOLTIP_HINT_TOKEN,
            useValue: false
        },

    ]
})
export class AppPageHeaderComponent {

@Component({
    selector: 'app-table',
    templateUrl: './template-file.html',
    providers: [
        {
            provide: BUTTON_SIZE_HINT_TOKEN,
            useValue: 'sm'
        },
        {
            provide: BUTTON_ICON_HINT_TOKEN,
            useValue: 'sm'
        },
        {
            provide: BUTTON_TOOLTIP_HINT_TOKEN,
            useValue: true
        },

    ]
})
export class TableComponent {

@Component({
    selector: 'app-card-header',
    templateUrl: './template-file.html',
    providers: [
        {
            provide: BUTTON_SIZE_HINT_TOKEN,
            useValue: 'medium'
        },
        {
            provide: BUTTON_ICON_HINT_TOKEN,
            useValue: 'md'
        },
        {
            provide: BUTTON_TOOLTIP_HINT_TOKEN,
            useValue: false
        },

    ]
})
export class AppCardHeaderComponent {

After doing this, we'll not have to specify buttonSize, buttonIconSize and showToolTip flag while using the app-button because the button component will get that from the context itself.

Please do let me know how you find this approach!

Thank you!

Your Angular code base is deprecated.

Shivam — Thu, 27 May 2021 23:27:40 +0000

No, upgrading to Angular 12.x.x will not help.
It's still deprecated.

The Typescript experimental decorators were based on TC39 proposal-decorators.

We use the same Decorators in our Angular codebase to create services, components and other Angular constructs.

But the same TC39 proposal has evolved in a different direction which is semantically not compatible with the experimental Typescript decorators.

The new spec for Decorators is easier to use and write.
This draft is still in stage-2 and may again change in the future.

You can find the detailed comparison between old and new decorators here.

Just finished up the first draft of the new decorators spec, pretty excited about it 😄 https://t.co/ELhZbsiaiR
— The p is silent (@pzuraq) May 27, 2021

Does this mean that Typescript experimental decorators will not be compatible with Javascript decorators 😨
— Shivam (@shivamd20) May 27, 2021

Unfortunately no, the new proposal has differing semantics from previous proposals in a number of ways. TypeScript experimental decorators were also incompatible with the Define semantics class fields, which caused a decent amount of breakage in the ecosystem.
— The p is silent (@pzuraq) May 27, 2021

When the proposal advances, figuring out a step-by-step incremental upgrade path for existing decorators users is definitely going to be a priority though! No user left behind 😄
— The p is silent (@pzuraq) May 27, 2021

Let's just hope that this doesn’t result in fragmentation of JavaScript decorators. We have already faced a lot inconvenience due to commonsjs and ES6 imports.