DEV Community: Nick Raphael

Redux: Uncaught TypeError: Cannot read properties of undefined (reading 'mySlice')

Nick Raphael — Tue, 21 Jun 2022 01:05:07 +0000

Oh man, I just had a really annoying redux-toolkit error...

Uncaught TypeError: Cannot read properties of undefined (reading 'mySlice')

This was caused by a circular dependency in my file structure. I have a file structure like this...

stuff
  -> store
    -> index.ts
       reducer.ts
       selectors.ts
  feature
    -> store
      -> index.ts
         slice.ts
         selectors.ts

Any code outside of the store files references store stuff via the index.tx which just exports all the other files.

My problem was a selector referencing a selector from a higher level in my store structure via another index.ts. The reducer at this higher level was referencing the slice at the lower level, again via index.ts.
This is a circular reference. To fix it, I chose to remove the higher level index.ts and reference the selector file directly.

Hope this helps somebody.

List git branches ordered by date of last commit

Nick Raphael — Mon, 10 Jan 2022 00:59:30 +0000

First day back after Christmas break and I'm a bit hazy on what I was working on. I know I was working on an area of code weeks ago but not sure if it got merged into Master.

Git can help. I'll list all my local branches by descending commit date. Luckily my branch names are taken from my workitem id.

git branch --sort=-committerdate  # DESC

I found the branch I was after near the top of the list. I then checked if the last commit on that branch was in master. Easy.

One to remember...

How to change the url of a remote git repo...

Nick Raphael — Tue, 07 Dec 2021 22:53:52 +0000

Hi all,

I recently got myself into the situation where all my local git repos had the wrong remote addresses. This was caused by a change up on our git account.

You can see the url that git is currently using by opening the 'config' file in the .git folder. You'll see it under the '[remote "origin"]' section.

Luckily this is pretty trivial to fix. You can either update the url directly in the config file, or run the following command...

git remote set-url origin new.git.url/xyz

Fixing VSCode terminal font

Nick Raphael — Thu, 11 Jun 2020 05:43:56 +0000

I just noticed that my vscode terminal window was having font issues. Especially obvious when it shows the git branch. Those little squares don't look right...

Take a look...

It's super easy to fix though. Download a powerline font (I like 'Cascadia Code PL') and install it on your machine.

Now all you need to do is add the following line to your vscode settings.json...



"terminal.integrated.fontFamily": "Cascadia Code PL"

And hey presto...

If vscode gives you any errors like 'terminal only supports monospace fonts' then you can try 'MesloLGM Nerd Font'.

Laters

With the ngrxLet directive we could get rid of that *ngIf trick that we lovehated

Nick Raphael — Wed, 22 Apr 2020 04:05:12 +0000

Note: As of writing (22-04-2020), ngrx/components is still experimental.

First, I'll go over the 'hack' that I'm talking about.

Let's suppose we have a rather uninteresting app that shows a different random value every second...

@Component({
  selector: "app-root",
  template: `
    index: {{ (timer$ | async)?.index }}<br />
    randomValue: {{ (timer$ | async)?.randomValue }}<br />
    randomValue again:{{ (timer$ | async)?.randomValue }}
  `
})
export class AppComponent {
  timer$: Observable<{ index: number; randomValue: number }>;

  constructor() {
    this.timer$ = timer(0, 1000).pipe(
      map((num: number) => {
        return {
          index: num,
          randomValue: Math.random()
        };
      })
    );
  }
}

Look at that template. Ugh, we had to repeat the '(timer$ | async)' every time we want to render a property of the object. But it's actually worse than that. Each use of async creates a new subscription. See how the two randomValues are different? Perhaps not what we might have expected.

So we started using a little trick. *ngIf can store a conditional result in a variable. This is fully documented on the angular docs. It allows us to avoid repeating the async bit.

template: `
    <div *ngIf="timer$ | async as randomNumbers">
      index: {{ randomNumbers.index }}<br />
      randomValue: {{ randomNumbers.randomValue }}<br />
      randomValue again:{{ randomNumbers.randomValue }}
    </div>
  `

You'll now see that the two random numbers are the same. Woohoo, we only have one subscription. That's great and far more efficient. As a bonus, we didn't need to use the '?' safe navigation operator. Our div was only rendered when the observable was truthy.

So what's wrong with that? Sounds perfect. And it almost is. We don't like the fact that we co-opted the *ngIf for something that wasn't really a show/hide issue. In fact, we may have a different *ngIf statement that we want to use here. Also, using *ngIf here can interfere with angulars rendering and if your observable returns a falsy value, your div will hidden. Messy.

Along comes ngrxLet which comes with ngrx/components. This library as a set of reactive helpers. There is a desire in the angular community to move away from zones, and ngrx/components helps us do that.

template: `
    <div *ngrxLet="timer$ as randomNumbers">
      index: {{ randomNumbers.index }}<br />
      randomValue: {{ randomNumbers.randomValue }}<br />
      randomValue again:{{ randomNumbers.randomValue }}
    </div>
  `

It only took a small update to our code. *ngIf is still available to us if we want visibility logic. That's a better seperation of concerns.

There are a few other magical advantages to using ngrxLet. It also passes us '$error' and '$complete' from the underlaying observable. Like this...

template: `
    <div *ngrxLet="timer$ as randomNumbers; let e = $error, let c = $complete">
      index: {{ randomNumbers.index }}<br />
      randomValue: {{ randomNumbers.randomValue }}<br />
      randomValue again:{{ randomNumbers.randomValue }}
      <div *ngIf="e">
        error: {{e}}
      </div>
      <div *ngIf="c">
        completed: {{c}}
      </div>
    </div>
  `

I hope this makes it into a full release from ngrx. I like it.

c# quicky. Should we 'throw;' or 'throw e;'?

Nick Raphael — Mon, 06 Apr 2020 01:57:01 +0000

This is a bit of an oldie. Very old, in fact, since this question has been around since c# was born. And likely before that for other languages.

What's the difference between these code snippets?

try
{
  ...some code
}
catch (Exception)
{
  throw;
}

try
{
  ...some code
}
catch (Exception e)
{
  throw e;
}

Well, it's all about where the exception originates and what happend to the stacktrace...

throw : Using a "throw" statement preserves the original error stack information. In exception handling "throw" with empty parameter is also called re-throwing the last exception.

throw e : Using a "throw e" statement, the stack trace of exception will be replaced with a stack trace starting at the re-throw point. It is used to intentionally hide stack trace information.

Most of the time you will want to 'throw;'.

Getting the min or max value from an array of numbers in javascript

Nick Raphael — Fri, 27 Mar 2020 04:56:08 +0000

Turns out this is simple. Well, it was simple anyway, but it's also quite concise.

I'll provide my code examples in javascript.

Let's suppose we have an array of number...

var myNumbers = [100, 50, 200];

We can use swanky destructuring assignment, which I know more commonly as the spread operator.

var myNumbers = [100, 50, 200];
var myMinNumber = Math.min(...myNumbers);
var myMaxNumber = Math.max(...myNumbers);

Short and sweet.

Got a 'git' conflict and just want to blow away your local changes and take 'theirs'?

Nick Raphael — Thu, 19 Mar 2020 07:01:40 +0000

I just did a 'git merge' with another branch and I have a merge conflict. I'm happy to lose my changes in preference to the changes on the other branch.

Well, as with all things, there is a simple git command for this...

git checkout --theirs path/to/file

Too easy.

Did you just say you want to 'git add' all those files except 1?

Nick Raphael — Wed, 11 Mar 2020 00:30:50 +0000

You run a 'git status' and see that you've updated a heap of files. One of those files you don't want to commit (often a config). What's the easiest thing to do? Well, I have a few options.

Option 1. Use 'git assume-unchanged'. I have a blog post about that here: https://dev.to/nickraphael/git-assume-unchanged-for-when-you-want-git-to-ignore-an-edit-for-a-while-2lig

Option 2. Just undo you edit before doing the add. Basically using 'git checkout xxx/dontcheckmein.txt'

Option 3. Run a 'git add .' to add all the files. Then run 'git reset -- xxx/dontcheckmein.txt'. This will undo the add.

Then you can 'git commit' to your hearts content.

Oops, I just pushed a git commit to the wrong branch. What now?

Nick Raphael — Thu, 23 Jan 2020 01:41:02 +0000

We are currently running off two active branches in our git repository. And by accident I just committed an update on the wrong branch and pushed it. Luckily, getting out of this mess isn't hard.

The erroneous commit is 65c356c8c

First, lets pull the commit from Branch1 into Branch2 where it should be...

   git checkout Branch2 
   git cherry-pick 65c356c8c

This pulls the commit across into the correct branch. Great. We can now push the commit is normal. But what about the commit still sitting on Branch1 in my local index? Lets fix that now.

   git checkout Branch1
   git reset --hard HEAD~1

This will reverse the last commit.

As with all git issues, the secret is to not panic. Jump on the net and find a simple solution.

Angular's providedIn: "root". What if two lazy modules provided the same service?

Nick Raphael — Wed, 18 Dec 2019 05:50:22 +0000

Sheesh, I'm not sure about that title. Let's unpack it a little. The modern way for an angular application to register a singleton service class is using providedin.

https://angular.io/guide/singleton-services

import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root',
})
export class UserService {
}

@NgModule({
  ...
  providers: [UserService],
  ...
})

What if we the module that provides the service is a lazy loaded module? Well, that service code will compile into the lazy loaded bundle for that module. Simple enough. But what if a second lazy loaded module also provides it? Where does angular (webpack?) put the service code? What bundle? Does it put it in the main bundle, in both lazy bundles or something else?

The answer is: something else. Angular is smart enough to realise there is a service that is shared between lazy modules. It puts that code in its own common module. Then whichever lazy module loads first, downloads the common module along with the lazy module. That way, the service isn't downloaded before it's needed and is still only downloaded once, despite being provided by two different lazy loaded routes.

Pretty clever.

The common misconception of @Injectable() in angular

Nick Raphael — Wed, 11 Dec 2019 23:42:00 +0000

The official angular docs give the following description of @Injectable()...

https://angular.io/api/core/Injectable
"Decorator that marks a class as available to be provided and injected as a dependency."

I think that description isn't right. Or at least it leads me to misinterpret the meaning. Let me start by defining a concrete example...

Let's say we have AppComponent and UserService. By default the angularCli will add @Injectable() to the service when it is generated.

Now, to me, the official statement makes me think that @Injectable() on UserService allows us to add it in the constructor of AppComponent as a dependency. "...marks a class as available to be provided and injected as a dependency". But what happens if we remove the @Injectable() from the service? Let me tell you - it still gets injected into AppComponent.

Now lets add a second service, OrderService and add it as a dependency of UserService. Now our application throws an error. "Can't resolve all parameters for UserService"

When we add @Injectable() to the UserService it actually allows UserService to have dependencies injected into itself. Not allow itself to be injected into AppComponent.

So we add @Injectable() to UserService since it needs to register with the dependency injected system to get a reference to OrderService. We can even remove @Injectable() from OrderService since it doesn't have any dependencies.

I'm not saying you should remove @Injectable(). In fact, you should leave it there even if your service doesn't have dependencies. It does no harm. I once had a service where the injected services weren't working and it took me ages to notice that @Injectable() was missing. So don't do that.

You might wonder why components are not marked with @Injectable() since they have dependencies injected into them. Well, if memory serves, any decorator will have the effect of registering the class with the DI system. So in this case @Component() is doing it.

Am I the only one who feels the description of @Injectable() isn't quite right? Let me know.