DEV Community: Arkadiusz Graczyk

From Spartacus to Composable Storefront: What Really Changed Around NgRx?

Arkadiusz Graczyk — Thu, 20 Aug 2026 10:30:56 +0000

Starting with version 5.0, SAP Commerce Cloud, composable storefront became SAP’s officially supported offering based on open-source Spartacus. The name changed; the architecture did not — not on that day.

NgRx was not removed. It is still part of the core architecture. What changed was how much new code needed to depend on it directly, especially for state originating from APIs.

In the pinned commit used here, @spartacus/core is version 221121.17.0. Its manifest still lists @ngrx/store, @ngrx/effects and @ngrx/router-store as peer dependencies. The current architecture guide still describes backend data as being held in a central NgRx store and exposed through facades.

What stayed

The documented data flow is:

Component → Facade → Store / Effects → Connector → Adapter → OCC

Facades keep UI code away from NgRx. Effects coordinate state changes and backend operations. Connectors delegate calls to adapters. These layers gave teams clear places to customise behaviour, but they also tied core flows closely to NgRx.

What changed

Spartacus 3.2 introduced proxy facades, so application code could depend on lightweight contracts while their implementations lived in lazy-loaded features.

The core-3.2.0 source already contains CommandService and QueryService. Adoption came later, feature by feature. The public guide now sits in the archived 4.x documentation, which makes the mechanism look newer than the tagged source. Checkout moved to Commands and Queries in a later migration. The code, documentation and adoption did not land together.

Commands and Queries handle backend-driven loading, caching and errors without requiring a full action, reducer, selector and effect chain. A Query can stay behind a facade method:

@Injectable()
export class UserProfileService implements UserProfileFacade {
  protected query = inject(QueryService);
  protected userProfileConnector = inject(UserProfileConnector);

  protected titleQuery = this.query.create(
    () => this.userProfileConnector.getTitles()
  );

  getTitles(): Observable<Title[]> {
    return this.titleQuery.get();
  }
}

Commands and Queries do not replace facades. The same facade contract can be backed by Store and selectors in one feature and by a Query or Command in another.

On one long-lived storefront I worked with, an older saved-cart feature still used the full action–effect–reducer–selector chain, while newer checkout code used Commands and Queries behind facades. Both worked. Rewriting the older flow would have added migration risk without changing what the customer saw. The facade was the useful boundary: new code could evolve without forcing the older state model to move with it.

Before adding another state flow

In a long-lived storefront, the cost of one more action, effect or selector is not the file itself. It is another path to trace while debugging and another customisation to carry through upgrades.

Before adding global state, ask:

Is there already a facade that exposes the behaviour I need?
Is this genuinely shared application state, or backend data with a lifecycle?
Can the customisation remain behind a connector or adapter instead of spreading into the UI and global store?

Voice Dictation Can Actually Handle Polish-English Code-Switching

Arkadiusz Graczyk — Wed, 13 May 2026 09:19:21 +0000

A few months ago I watched a colleague leave a code review comment by talking into his microphone.

He said something like:

The observable chain here has a race condition because the switchMap isn't cancelling the previous subscription.

The transcript came out clean. It even got switchMap right.

My first thought was: sure, in English. No chance this survives contact with the way we actually talk about software in Poland.

I was wrong.

Polish-English Was the Real Test

English wasn't the interesting part for me. What surprised me was how well the dictation handled the Polish-English hybrid that shows up in everyday developer conversations: Polish grammar mixed with English API names, framework terminology and architecture vocabulary.

For example:

What I said	Result
🇵🇱 "Refaktoryzacja serwisu do obsługi płatności"	Exact
🇵🇱 "Wstrzykiwanie zależności przez konstruktor"	Exact
🇬🇧 "Add a circuit breaker pattern to the external API calls"	Exact
🇵🇱🇬🇧 "Ten endpoint powinien zwracać paginated response"	Exact

The fourth example was the one that changed my mind. "Ten endpoint powinien zwracać paginated response" is not particularly good Polish or good English, but it is completely normal developer Polish. That's how a lot of us actually speak at work.

It isn't perfect, though. I still have to correct the occasional word or technical term, and that's fine. Fixing one or two words is still easier than typing the whole explanation from scratch.

What I Actually Dictate

I'm not dictating code. Voice is a bad fit for syntax-heavy work where exact punctuation and structure matter.

Where it works for me is everything around the code: explaining why something works, why it doesn't, what changed and what another engineer needs to know. In practice that means PR descriptions, Slack messages, longer review comments and the occasional first draft of internal documentation.

PR descriptions

Right after finishing a feature, all the context is still in my head: what changed, why I changed it, which edge cases showed up, what I deliberately didn't solve and which trade-offs I made.

Typing all of that into a PR description can feel like reconstructing work I've just finished. Talking through it feels more like continuing the same train of thought.

The transcript can be messy. I mostly care about getting the reasoning out while the context is still fresh.

Slack and review comments

This is where the Polish-English mix actually shows up. A message might start in Polish, switch to English for a technical term, include an API name, and go straight back to Polish grammar. That's the part I expected voice dictation to struggle with, and the part that surprised me most.

It also changes what I end up writing. Typing pushes me towards shorter explanations, which is how you get review comments like:

This should probably use switchMap.

Speaking makes it easier to include the reasoning instead of compressing the comment down to a one-line suggestion.

A Real Example

Here's a real Slack message I dictated in one take:

Hej, zerknąłbyś na akcję Dry Run? Wydaje mi się, że nie przekazujemy zmiany do ECS, przez co nie eksponuje logów.

And after a quick cleanup:

Hej, zerknąłbyś na akcję Dry Run? Wydaje mi się, że nie przekazujemy zmiennej do ECS, przez co nie eksponuje logów.

The transcript was almost right, but Willow transcribed zmiennej as zmiany. The sentence still looked plausible, but that one word changed the meaning.

For me, that's still a good trade-off. Fixing one word and adding a bit of formatting is much easier than typing the whole message from scratch.

What I Use

Someone recommended Willow Voice to me, so I tried it. I use the free version, and for what I need it for, that's enough.

I hadn't used voice dictation tools before, so I can't meaningfully compare Willow with Superwhisper, local Whisper, macOS Dictation or anything else. It worked well enough, and I kept using it.

That's about as sophisticated as my tool selection process was.

Where It Doesn't Work

Open offices are awkward. I don't have a clever solution for that; I dictate at home or somewhere I can talk without annoying everyone around me.

Very short messages aren't worth it either. If it's a single line, I usually just type it.

And the transcription doesn't have to be perfect to be useful. I still fix occasional technical terms, remove false starts and add formatting afterwards. Editing is part of the workflow, not a failure of it.

Fully voice-controlled programming still sounds exhausting to me, and I have no interest in replacing the keyboard. I just stopped using it for some of the writing around software development, and it turns out there was more of that in my week than I expected.

I also have no reason to assume Willow is the best option just because it's the one I happened to try first. If you've used Willow alongside something else — especially for multilingual or code-switched speech — what worked better for you, and why?

Angular & the "Disappearing this": Why Arrow Functions are More Than Just Syntax Sugar

Arkadiusz Graczyk — Thu, 09 Apr 2026 19:08:08 +0000

Let's be honest — when was the last time you typed the word function inside an Angular component? Probably never. We all reach for () => {} like it's muscle memory. In .subscribe(), in setTimeout(), inside RxJS operators — arrows everywhere.

But have you ever actually stopped mid-keystroke and thought: "wait... why do I always do this?"

Spoiler: it's not just because it's shorter.

"Let's get back to the basics — not because they're simple, but because they're hiding in plain sight."

You've probably typed () => a hundred times this week. Inside a .subscribe(), a .pipe(), a .map(). It works, you ship it, you move on. But the moment you ask "why does this actually work?" — that's where it gets fun.

So let's look at something you already know... but maybe never really noticed.

When `this` Has an Identity Crisis

Here's the deal with JavaScript: the value of this is dynamic. It depends on how a function gets called, not where you wrote it. And that... can mess things up.

Check this out:

@Component({
  selector: 'app-status',
  template: `<h1>Status: {{ status }}</h1>`
})
export class StatusComponent {
  status = 'Initializing...';

  updateStatus() {
    // ❌ The "Mercenary" — works for whoever calls it
    setTimeout(function() {
      // Surprise! 'this' is NOT your component anymore.
      // It's either 'undefined' (strict mode) or 'window'. Oops.
      this.status = 'Ready!'; // 💥 boom
    }, 1000);
  }

  updateStatusFixed() {
    // ✅ The "Loyal One" — remembers where it came from
    setTimeout(() => {
      // 'this' is still our component. Always.
      this.status = 'Ready!';
    }, 1000);
  }
}

The first version? Compiles just fine. Zero warnings. But at runtime, this.status either blows up with a TypeError or quietly updates some random property on window that no one will ever read. Your template is stuck on "Initializing..." and you're staring at the screen like 🤔.

The second one just... works. Every single time.

OK Cool, But Why Does the Arrow Work?

There's a fancy term for this — Lexical Scoping — but honestly, the concept is dead simple:

Regular functions create a fresh this every time they run. When setTimeout fires your callback, it has no idea your component exists. So this becomes... well, nothing useful. undefined in strict mode, window in sloppy mode.

Arrow functions just don't bother creating their own this. They grab it from wherever they were written. In your Angular component? That's your component instance. Done.

So What's Actually Happening Behind the `=>`?

Today, every modern browser understands arrow functions natively — and Angular hasn't targeted ES5 in years. So no, the compiler isn't rewriting your arrows into something else.

But back in the ES5 days, it did. And looking at what it produced is the best way to understand what an arrow function actually means:

// What you write (modern):
updateStatusFixed() {
  setTimeout(() => {
    this.status = 'Ready!';
  }, 1000);
}

// What compilers used to generate (ES5):
StatusComponent.prototype.updateStatusFixed = function() {
  var _this = this;  // ← That's it. That's the whole trick.
  setTimeout(function() {
    _this.status = 'Ready!';
  }, 1000);
};

See it? No magic. Just saving this to a variable before the callback has a chance to lose it. That's literally all an arrow function does — it just does it for you, invisibly, at the language level.

The var _this = this era is gone, but the mental model is still gold: arrow functions lock in the surrounding this so it can't be overwritten.

A Tiny History Lesson: `.bind(this)`

Before we had arrow functions, people solved this with .bind():

updateStatus() {
  setTimeout(function() {
    this.status = 'Ready!';
  }.bind(this), 1000);  // ← "please remember who I am"
}

It works! But it's clunky, easy to forget, and creates an extra function every time.

Arrow functions didn't reinvent the wheel — they just made it spin easier.

"Yeah But I'd Never Use `function()` in setTimeout Anyway"

OK fair, that example is a bit textbook-y.

But here's the thing — this exact mechanism is quietly saving your butt every day in code you don't even think about. You've probably written this kind of thing a dozen times today:

@Component({ /* ... */ })
export class UserDashboardComponent implements OnInit {
  users: User[] = [];
  errorMessage = '';
  selectedRole = 'admin';

  constructor(private http: HttpClient) {}

  ngOnInit() {
    this.http.get<User[]>('/api/users').pipe(
      map((users) => users.filter(
        (u) => u.role === this.selectedRole  // ← 'this' = component ✅
      )),
      catchError((err) => {
        this.errorMessage = err.message;     // ← 'this' = component ✅
        return of([]);
      })
    ).subscribe((users) => {
      this.users = users;                    // ← 'this' = component ✅
    });
  }
}

Three arrows, three times this means "my component." Now picture swapping any of those => for function():

// 😬 don't try this at home
.subscribe(function(users) {
  this.users = users;  // 💥 'this' is undefined — data goes nowhere
});

RxJS calls your subscribe callback. The Observable pipeline calls your map. The error channel triggers your catchError. None of them care about your component. The arrow function is the only reason any of those this. references work.

You knew this code worked. Now you know why it works.

"What About Signals Though?"

I can hear you: "We're moving to Signals and Zoneless Angular — is this even relevant anymore?"

Oh, 100%. Even in the shiny new Signal-based world, your state still lives inside a class. And that class still needs this:

@Component({
  selector: 'app-counter',
  template: `<h1>{{ count() }}</h1>`,
})
export class CounterComponent {
  count = signal(0);

  constructor() {
    effect(() => {
      console.log(`Count changed to: ${this.count()}`);
      //                                 ^^^^ yep, still needs 'this'
    });
  }
}

signal(), computed(), effect() — they all hang off this. Whether you're calling this.count.set(5) or this.count.update(v => v + 1), a stable this is what makes it all tick.

The APIs change. The fundamentals? Not so much.

Got a good this-related horror story? Drop it in the comments — I bet we've all debugged that one mysterious "Cannot read property of undefined" at least once. 😄