Putting it shortly: everything has changed since I last posted here. EVERYTHING.

This blog post is my retrospective on the last 18 months. Personal. Self-healing. Unblocking.

Moved back to Poland

After 6 years of traveling and working remotely, my wife and I decided to come back to Poland. When we left, there was no specific goal. We just wanted to explore and live this life (and we did to the fuuuuuullest and we still are!). Somewhere in the back of our heads there was this idea of finding a better place. An ideal place to settle down. But as it turned out, no place is perfect. Even living in the paradise of Indonesia for 15 months had its flaws

However, the best side effect (or maybe the main effect) of living in several different countries is the new perspective. Being back in Poland now (which is an amazing country) hits completely different than it was those ~7 years ago. I appreciate it 100000 times more. I am constantly amazed by little things that I previously took for granted or didn’t even notice. This gives me a unique perspective on living here and I really appreciate that.

Longer trips and workations will resume, but for now I am proudly calling myself a self-retired digital nomad

Switched to Mac

In mid-2025, I decided to switch to a Mac. I’ve always been a .NET guy, on Windows since 1998 , but my new job eliminated working with legacy desktop stuff, so I could make the move. I bought a 16-inch MacBook M4 Pro with 48GBs of RAM and 512 GBs of disk space. I was a little worried about the disk space, but after ~1 year it’s just enough for me. Just checked and I still have 260GBs of free space (did the cleanup a few days ago though, before that it was around 180 GBs free). My daily toolbox includes Rider, VS Code, .net&npm, Claude Code, 6-10 docker containers and a few smaller local LLMs running in LM Studio.

I wouldn’t believe saying this 2 years ago, but switching to Mac was the best decision ever. There’s even nothing to write about here. It’s just amazing and I can finally work 8-10 hours without charging it – just in time when I retired from full-time nomading

Started working for a fully remote SaaS company

I also started working for an Australian, fully remote SaaS company. We are building a platform for healthcare professionals, mostly from Australia, US and the UK. The teams are distributed all over the world, but we are not a corporation (there’s probably around 90 of us currently, including ~40 engineers).

It’s been challenging for me to move from a software house to working on an actual SaaS product, which comes with more responsibility, but also more possibilities and influence on the product.

AI… AI everywhere

I didn’t want to start with this point, but this is HUGE. When writing my last article here, in December 2024, the only AI I used was probably the tab completion with GitHub Copilot in VS Code. Early days Since then, my working turned upside down.

I hope to write down more about it one day, but TLDR:

I went through different tools (Cursor, Zed) to – for now – settle down with Claude Code and Codex, which I use every day. Today, I write the definitive most of my code with AI. I also research with AI. I’m building features leveraging LLMs, which bring amazing value to the users. I’m thinking much more about the product, the actual usage of it, the value for the end users, the architecture, security, deployments than about which C# features to use or how to structure the code on the lowest level. I don’t remember when I last visited StackOverflow

And it’s not only work! AI also completely refactored my personal life. I make appointment notes with AI. I research stuff to buy with AI. I rarely use pure Google search. I vibe code apps for solving my daily issues like managing home finances or learning a new language. Fun times

Code generation

I’ve already mentioned this above, but code generation should have its own paragraph. I’ve never been a developer who loves to write code. I always enjoyed everything around it – analyzing customers’ needs, finding architectures that solve the issue, connecting different dots in the project, coordinating cross-team cooperation, maintaining the documentation or even writing tests. So code generation with AI is something I welcomed with open arms

As I’ve already mentioned, the vast majority of my code is AI-generated. I focus more on planning and reviewing it. It opens so many possibilities. I am also never hesitant or feeling blocked to start working on a task, because I always have a place to start – an AI agent.

AI Devs course

A huge step in my AI journey was taking and completing the AI Devs course. It’s been crazy 5 weeks of intensive learning about LLMs, AI agents and multimodality. Very practical, focused on solving real tasks. The course equipped me with solid foundations of the LLMs before the biggest shift with Claude Code and Opus 4.5 happened. It reminds me of diving into .NET internals years ago, just so today I can understand C# and the framework much better. It also opened my eyes to the possibilities LLMs give us. Things that were impossible (or very hard) to realize with pure code are now at our fingertips.

Attended non-technical tech conference

By the end of September 2025 I attended Beyond Code conference. It’s probably the only non-technical IT conference in Poland. The talks and discussions were focused around well-being, mindfulness at work, soft skills and psychology. Very needed type of events, especially in this crazy AI era.

Gave my first public talk

Another significant event was giving my first public talk at a local meetup in Bielsko-Biala. I presented my approach to working with AI tools and how we transformed the software development at the company I work for. The feedback I got was very positive and it was a very rewarding experience

I was invited to a podcast

Last but no least, as kind of an aftermath of the meetup talk, I was invited to an AI podcast episode. Przemek, who is one of the co-founders of Przeprogramowani (an initiative where the guys teach about AI development, basically), happened to attend my talk at the meetup and later invited me to record the podcast episode. We talked about AI again, this time in more depth. I also shared a little about digital nomad life. The episode got quite a lot of traction and positive feedback.

So… what’s next?

Ufff, I’m very happy that I got to this point. I really wanted to publish this article. I know it’s very personal, but that’s what I needed.

To be fully honest, I have no idea what to do with this blog. When I finally sit to it, I really like writing. This is by the way very common in my life recently – I commit to many projects that I really enjoy when actually working on them, but then I have no time to even start working on them, because they are too many

AI have completely reshaped the way I work and also changed my identity. I don’t anymore see myself as someone who will “help you becoming an independent full stack .NET web developer”, as the description in the sidebar of this page still says The free PDF I’m sharing as part of newsletter signup is completely out-of-date now. I don’t even know how I would need to reshape it to fit the current AI era

I don’t really know what’s next. Next for this blog, as well as for my activity in the IT community. Everything changes so fast… But maybe this is what we all found ourselves in right now? Maybe we just need to accept the current pace of things, outdated websites and blogs, as well as AI tools that become legacy a few days after being released?

The post Everything Has Changed appeared first on CodeJourney.net.

In this article, I’m sharing a compiled list of the most popular .NET interview questions I was asked during all those interviews. They represent real questions asked on job interviews for a software developer with almost 10 years of experience. Hope you enjoy it

Technical .NET Interview Questions

1. What’s the difference between a class and an interface?
2. What’s the difference between an abstract class and an interface?
3. What is the difference between a class and a struct?
4. Describe the difference between overriding and overloading in C#
5. Can a structure have virtual methods?
6. Explain the difference between GET, POST and PATCH in HTTP APIs
7. Is there any limit go the GET request’s length? If yes, where is such a limit configured? What about POST?
8. How would you secure your WebAPI?
9. What is the flow of generating, obtaining and passing JWT token in a .NET application?
10. When using JWT tokens in an API, how does the server ensure it talks to a legitimate client?
11. Is the API security compromised when the user’s JWT token is stolen?
12. What is the difference between IEnumerable and IQueryable in the context of Entity Framework?
13. What are the dependency injection scopes in ASP.NET?
14. How can dependency injection be helpful in testing?
15. What is IHttpClientFactory used for and which issues does it help to eliminate?
16. What is wrong with creating HttpClient manually?
17. What would you choose for implementing communication between microservices: REST or a message broker? What would you consider when making such a choice?
18. What would you do as a backend developer when frontend developers are blocked because they are missing an API endpoint from your side?
19. What is the size of stack in .NET?
20. What are value and reference types? What is the difference between them? Give a practical example
21. Which objects go on Large Object Heap?
22. What is JIT compilation?
23. Describe the strategies for delivering a message in a message queue
24. When is Dispose method called on a class implementing IDisposable?
25. What is the difference between Dispose and Finalize?
26. What is SOLID? Can you elaborate on each SOLID acronym?
27. You are assigned a task to process a large piece of text by inserting and changing many parts of it. Which of the following would you use for that task: string, StringBuilder, StringWriter or StringReader?
28. What’s the difference between Repository and Query Object patterns?
29. What is the Saga pattern?
30. What is CQRS and in which scenarios may it be beneficial?
31. What is the difference between an event and a command (like in CQRS)?
32. What are the advantages and disadvantages of using a Repository pattern?
33. What is Clean Architecture? Who invented it and how it works?
34. What is Onion Architecture?
35. What is Modular Monolith?

Experience-related .NET Interview Questions

36. Describe how you realized authentication & authorization in your last project
37. Explain your last project’s architecture
38. Explain a challenging task you faced in your last project and how you solved it
39. How would you approach diagnosing a performance issue on production, which cannot be reproduced locally?
40. Explain the “event-based architecture” you implemented in your last project. This was something I explicitly mentioned in my resume, so the advice is: prepare to elaborate on every experience you mention in your resume
41. How would you choose tech stack for a new full stack web application (backend + frontend)? Describe your decision-making process: what would you take into consideration when choosing a tech stack?
42. How would you decide whether to use an already-existing component (e.g. a library) vs implementing your own?

Final tips

These were not all of the questions I was asked, but the ones that recurred most frequently. As a programmer with almost 10 years of professional experience, I wasn’t asked many basic programming questions. The recruiters were mostly focused on my experience. They wanted to know how I solved problems at work in the past and what’s my approach to tackling issues. Rather than asking me theories about a design pattern, they wanted to know how I applied it in practice and whether I was happy with deciding to use it in the first place.

My general advice is to be patient and iterate. After each technical interview, try to write down as many questions as you can remember. This will help you be better and better prepared with each interview you take. Don’t forget to update your LinkedIn profile and keep building a quality network, even if you’re not on the job lookout right now. It comes in handy!

If you happen to be in a work search right now, I keep my fingers crossed! I hope these .NET interview questions will help you get that dream job

If you’re interested in knowing something about programming job search in current market conditions, feel free to leave a comment

The post Real .NET Interview Questions (2024/2025) appeared first on CodeJourney.net.

The answer to all these questions is mutation testing. Interested? Read on

Code Coverage – Our Old Friend

You probably know what code coverage is. Traditionally, many teams tend to measure how good their tests’ suite is by percentage line / statements / functions coverage. Some even require this metric to be 100%. Let’s start with this well-known approach first.

We are working with TicketsPriceCalculator class today. It contains some simple business logic:

As you can see, the class has one function whith returns the total price to be paid for a set of tickets. On the way, it applies various discounts based on some business rules. Fair enough.

It’s a critical piece of business logic for the app we’re working on, but it has never had any tests. We were asked to write unit tests for this class. Our manager strictly requires the code coverage to be 100%. Let’s do it then. We will go line by line, analyze the business logic and add the tests. Below, you can see the results of running those tests (you can find the tests code here):

Wow, that’s awesome! We did a great job. We have 8 unit tests which provide 100% statements, branch, functions and lines coverage!

So now we are really safe, aren’t we?

Yeah… until you know what mutation testing is

What Is Mutation Testing?

The idea of mutation testing is to mutate (change) our code. Mutation testing tools introduce changes into our production code. These changes can be really anything – from reverting a condition of an if statement, to changing some operators or changing a string value. For instance, here are some logical mutations Stryker Mutator is able to introduce (you can find the list of all mutations supported by Stryker here):

In effect, they generate modified versions of our code, which are called mutants. Makes sense

Each mutant contains a single modification in our source code. What happens next is crucial. Mutation testing tool takes this mutant (it is used as the code under tests now) and executes all of our unit tests against it. The result may be twofold:

• all tests have passed. In other words, the mutant has survived. This is a bad situation. It implies that the modification of our source code was not detected by our tests
• at least one test has failed. In other words, the mutant has been killed. This is a good scenario. It means that our tests detect changes in the production code and efficiently cover this particular scenario.

The flow is more or less like this schema from Peter Evans’ blog presents:

But why would anyone change the production code on purpose by introducing some stupid changes? It may seem counterintuitive for now, but let’s see how we can use it to our leverage.

Mutation Testing with Stryker Mutator

Let’s clearly state what we are starting with:

8 unit tests, 100% code coverage

Let’s now run mutation testing on our code. We are using TypeScript here, so let’s go with Stryker Mutator.

Here’s the result of running Stryker with npx stryker run on our code:

As you can see, 53 mutants were killed, but 15 of them survived. This gives us a mutation score of 78%. Let’s call it mutation coverage from now on. So to make it clear, this is our starting situation:

8 unit tests, 100% code coverage, 78% mutation coverage

Let’s now see how to kill those remaining mutants.

Killing First Mutants

In order to kill the mutants and improve our mutation score, we need to write more unit tests. Sounds logical, doesn’t it?

If still not, let’s take a deeper look at mutation tests results in VS Code. Stryker lists details of every survived mutant, for example this one:

Stryker changed the greater or equal (>=) operator to greater operator (>). This is a very common and very useful mutation. It usually means that our tests don’t cover the edge case associated with this particular condition.

In this case, the edge case value seems to be 5. More precisely, what happens if the number of business class tickets is exactly 5? We don’t know, because there is no test for this particular edge case!

Let’s add it:

The test passes. Let’s run mutation tests again:

That’s it! We have a new unit test and 1 more mutant killed Current state:

9 (+1) unit tests, 100% code coverage, 79% mutation coverage

I think you’re now getting what this is all about. We should be adding unit tests to cover the edge cases detected by mutations until all (or most) mutants are killed.

Mutation Testing – Free Unit Tests Generator

After adding 1 more test, the results look as follows:

10 (+2) unit tests, 100% code coverage, 86% mutation coverage

Finally, this is what we managed to get after a few minutes of work:

And we now have 17 unit tests in our suite! The final score looks like that:

17 (+9) unit tests, 100% code coverage, 96% mutation coverage

Notice what happened here. We started with 8 unit tests and finished with 17! This is awesome! That’s how mutation testing is a free unit tests generator. And you don’t even need AI for that

What’s more, the generated mutations even forced me to make a little tweak to the production code. It exposed some things that didn’t make sense. I could make this change to the production code, because my tests’ suite was already quite substantial.

Note that I didn’t push to gain 100% mutation coverage. The 3 mutants that survived don’t make much sense in our case. I encourage you to get the code and execute npx stryker run in the application folder to see for yourself

The percentage value doesn’t matter in that case. What matters is that we got 9 new unit tests and our tests’ suite is more robust. Now we can go and tell our manager that the business-critical code is well tested

So What Now?

I hope you see how valuable mutation testing is. It’s not a perfect tool that suits all cases. For example, it’s not easy to use mutation testing for complex legacy code. However, if your logic is nicely isolated, it could be a great tool. Especially if your production code heavily depends on calculations and many conditions. You may be surprised how many edge cases mutation testing can find.

I also love using mutation testing with TDD. These two techniques nicely complement each other.

I encourage you to go and try mutation testing. There are different mutation tools for various programming languages:

• C#, JavaScript, TypeScript, Scala: Stryker Mutator
• Ruby: mutant
• Java: pitest
• PHP: Infection
• C++: Mutate++

…and probably many more. Just do some research for the language you work with and give it a try Because testing is cool, isn’t it?

You can find the full source code used in this article here.

The post What is Mutation Testing and Why Should You Use It? appeared first on CodeJourney.net.

In this short article, I will give you my 5 reasons why the backend code editor might not be the best IDE for frontend development

NOTE: calling this post a “rant” is obviously humorous This article is my own opinion, not a hate on anyone using different IDEs than I do.

1. Rider and Visual Studio are slow

While I consider Rider much faster than Visual Studio, even the JetBrains editor is too heavy for TypeScript development. Both of these apps are not good candidates for an IDE for TypeScript. They were designed to work with complex, backend solutions. These IDEs include a lot of features by default that can’t be turned off, most of which are not needed when working with frontend code.

This gets even worse if the solution you open contains both backend C# project and React app’s code, as it is in Visual Studio’s .NET+React template. With time, even loading such a solution takes a lot of time. Especially if you use Visual Studio with ReSharper

2. Less IntelliSense and tooling support

From my experience, Visual Studio doesn’t show as much IntelliSense info as, for instance, Visual Studio Code does. The navigation in TypeScript code doesn’t feel as smooth as it should.

When I tried to use Rider or Visual Studio as IDE for TypeScript, I had issues working with popular frontend tooling like Prettier and ESLint. Theoretically, there are plugins for both of these IDEs, but in my experience they don’t always work properly. For instance, the “Format on save” feature of Prettier often doesn’t work in Rider for me. ESLint makes Visual Studio even slower (is that even possible?! ).

It’s hard to fully explain if you only worked with TypeScript in Rider or Visual Studio, but I promise you that switching to VS Code makes a huge difference Read on to get to know why!

3. Confusion of concepts

Let me explain my approach to frontend and backend first. To me, as a full stack developer, working on a frontend app requires a different mindset than working on backend. For instance, developing a React app requires me to think The React Way (we discussed it already in an article about React state management).

In my view, editing both frontend and backend code in the same editor makes you confuse concepts. If you learned JavaScript/TypeScript after working with C# for some time, you probably experienced trying to use let in C# or declaring C# types with colon (:) But this is only a tip of the iceberg.

I think having a separate IDE for TypeScript makes you nicely switch context when working on the frontend app. Opening my TypeScript code editor, I immediately start thinking in frontend. It instantly switches my approach to writing code. I somehow start to behave like a frontend developer, not a full stack one.

I think such approach is beneficial. For instance, it lets me work on my frontend code as I would be a real consumer of the backend API, not the person who can implement the backend in whichever way I want. Thanks to that switching of viewpoint, I can focus on designing my frontend code properly, without worrying about the backend.

I also tend to make less assumptions like oh no worries, I will do it on the server. At that moment, with my IDE for TypeScript open, I am a frontend developer. It often leads to better API design later on, because I don’t make any assumptions about the backend. Working on a frontend part of the app, I usually use API mocks first, knowing only the shape of data that should come from the API. Only later, when I’m done with the frontend part, I switch to Rider to actually implement the API.

Of course, this can also work the other way around. You can first work on the backend, design your API according to the best practices (again – without even thinking about your frontend app) and finally switch to the frontend IDE, build the UI and consume the API instead of using mock in the first place.

I hope you got what I mean here, but it’s not easy to clearly explain

4. Temptation to sneak C# concepts to TS

This point is a consequence of the previous one. If your IDE for TypeScript is the same as your C# code editor, you will be tempted to sneak C# concepts into TypeScript. I often see .NET developers entering TypeScript world using var by default (which is kinda deprecated in JavaScript and considered a bad practice today) or enforcing C# brackets formatting style in their frontend code. I also noticed overuse of classes and inheritance in TypeScript, as well as confusing passing value/reference data directly into components instead of properly using state and props in React.

To sum it up: isolating yourself as a frontend developer by using a TypeScript-specific IDE (like VS Code) will help you learn good frontend practices quicker

5. Because VS Code is better

Last, but not least: the main reason to not use Visual Studio or Rider for TypeScript development is simple: Visual Studio Code is better!

VS Code is industry standard for frontend development today. According to Stack Overflow Developer Survey 2023, over 70% of all developers use Visual Studio Code:

VS Code is lightweight. It doesn’t have all heavy features included by default. If you want something additional, it must be installed as an extension. By the way, the extensions are really great and actively developed by the community.

VS Code is mostly written in TypeScript, which makes is somewhat designed for TypeScript. It has great search features, awesome IntelliSense for TypeScript and works really fast. Especially compared to Visual Studio or even Rider.

Visual Studio Code can also be run on any platform. It even has a fully-featured web version. The IDE is also completely free and open-source.

I think I won’t continue listing numerous advantages of VS Code here. If you’re reading this, and you are still not encouraged to switch to VS Code for TypeScript development, please give it a try Or another try if you already tried, but it didn’t click. This time, first watch some introductory videos with tips on how to get started and get the most of the editor. You can also check the VS Code extensions I use on a daily basis to make your work with this editor easier.

Summary

That’s it! I really wanted to write this article one day. Do you know that feeling when you learned something new or made significant progress in some area of your life, and you see people still struggling with what you have overcome? It’s this moment when you would really love to give these people all of your knowledge and make them magically change their lives – the same way you did I feel exactly that when I see fellow developers struggling (it’s a matter of opinion, I know ) with Typescript in Visual Studio

I know I can’t change you and your beliefs and I don’t want to do that. But the great thing is that I can share my point of view and try to encourage you to alter yours a little. At least try and let me know what are your thoughts on that

Also, if you’re a frontend or full stack developer working in a backend IDE like Rider or Visual Studio, let me know why! I’m really curious. Did you try VS Code? If yes, what didn’t fit?

The post 5 Reasons To Not Use C# IDE For TypeScript Development appeared first on CodeJourney.net.

So what is React state management? How is it different from managing data in C# or Java? Let’s find out!

State

If you are a backend or desktop developer, you may have never come across the term of state. At least, I never used it before learning frontend web development. Surely not in the context it is used in frameworks like React. The term more familiar to me at that time was data binding known from WPF or WinForms.

This is what WPF documentation says:

Data binding is the process that establishes a connection between the app UI and the data it displays. If the binding has the correct settings and the data provides the proper notifications, when the data changes its value, the elements that are bound to the data reflect changes automatically

In case of WPF, the crucial part to me is If the binding has the correct settings and the data provides the proper notifications (…). If you have ever worked with WPF, you know how frustrating can these notifications be (any INotifyPropertyChanged fans here?).

WPF’s state management it not that bad. However, React has something better

React introduces us to a concept of state. In React components, you do not set anything directly, like calling some code to update an input’s value (this is possible, we’re still in JavaScript world, but it’s not a React way of doing stuff). You don’t directly bind your UI controls with data like you would in WPF or WinForms. Instead, you keep the data in memory, which is a current state of the UI (the whole app or a piece of it).

When the state changes, your UI is updated by React. In other words – in React, UI is a function of state:

UI = fn(state)

It means that your React app (or its individual pieces called components) take some state and output the actual, rendered UI.

This is React state management in a nutshell. Let’s explore it a bit more

Small disclaimer: I will focus on state in React functional componets. I consider class components somewhat legacy. I think this meme summarizes it best :

The Naive Way

Let’s try to approach React state management as C# developer. In React, the basic piece of UI we create is a component. Let’s add one:

import Button from "react-bootstrap/Button";

export const NaiveComponent = () => {
  return (
    <>
      <div>I am a naive component</div>
      <Button variant="success">Click me!</Button>
    </>
  );
};

For now, we render some text and a button which does nothing. What we want is to have some data displayed, like a number, which is incremented on every button click. Let’s try to implement that naively:

export const NaiveComponent = () => {
  let myCount = 0;

  return (
    <>
      <div>I am a naive component</div>
      <div>Current count: {myCount}</div>
      <Button
        variant="success"
        onClick={() => {
          myCount＋＋;
        }}
      >
        Click me!
      </Button>
    </>
  );
};

Now, let’s check if it works:

It looks nothing happens To investigate that, we can add a console.log (the most common debugging technique in JavaScript world ) to the onClick event:

onClick={() => {
          myCount＋＋;
          console.log(myCount);
        }}

How does that look in the console now?

Woooow, something is really going wrong here! The data is updated in memory, but not reflected in the UI

Why does that happen? Because myCount is not a state. It’s just some variable we created hoping that it will work fine as part of the UI. Remember what we have discussed in the previous section – we need to start thinking in React. This is The React way, not Java way or C# way anymore.

The React Way

So, how to use React state management properly in our example? We need to make myCount be a part of component’s state. The simplest way to do that looks as follows:

export const TheReactWayComponent = () => {
  const [myCount, setMyCount] = useState(0);

  return (
    <>
      <div>I am a React Way component</div>
      <div>Current count: {myCount}</div>
      <Button
        variant="success"
        onClick={() => {
          setMyCount(myCount ＋ 1);
        }}
      >
        Click me!
      </Button>
    </>
  );
};

First, instead of declaring a “normal” variable for storing our UI-related data, we used the useState hook. As you can see, it returns an array with two things: our state variable (myCount) and a function to update its value (setMyCount). We also set the initial value to 0. A good practice is to always use a construct like [myCount, setMyCount] to destructure what useState returns into named, separate objects.

Now we are managing our component’s state The React Way. Does it work? Let’s see:

Great! We have just learned how the basic form of state management works in React. That was easy, wasn’t it?

Now, let us discuss one more aspect related to the state itself.

Reference vs value

We know the React Way for state management now. We feel confident. However, we are also used to how data is managed in C# or Java, especially in terms of handling reference and value types. This knowledge will come very handy now

Let’s try to create a bit more complex component:

type Person = {
  id: number;
  name: string;
  age: number;
};

export const ObjectHolderComponent = () => {
  const johnInitialValue: Person = {
    id: 1,
    name: "John Doe",
    age: 30,
  };

  const [john, setJohn] = useState<Person>(johnInitialValue);

  return (
    <>
      <div>ID: {john.id}</div>
      <div>Name: {john.name}</div>
      <div>Age: {john.age}</div>
      <Button
        variant="success"
        onClick={() => {
          const currentJohnObject = john;
          currentJohnObject.age = currentJohnObject.age ＋ 1;
          console.log(currentJohnObject);
          setJohn(currentJohnObject);
        }}
      >
        Make John older
      </Button>
    </>
  );
};

Now, instead of storing a single value in our component’s state, we store a whole object of type Person. The object has a few properties: id, name and age.

There is also a button. We want this button to take the current john object, increment the value of age on it and update the state. We do it The React Way using setJohn function returned by useState. Just to be sure, we also have the console.log(john) just before updating the state. Does that work as we expected?

Eh, what’s happening here this time? We can clearly see that age is updated on the object on each click, but why isn’t the UI re-rendered?

As I mentioned before, it’s critical to understand the difference between reference and value types here. If you don’t know it, go and make up for it now.

The reason it does not work is that we haven’t updated the actual content of john state variable by calling setJohn(currentJohnObject). What is really being hold in john variable is the reference (pointer, address in memory) to the actual object. And this is what React tracks. We didn’t really update it, because we assigned the same instance of the object to the state. It doesn’t matter that we updated its internal property age – the reference itself wasn’t updated.

How do we solve that? Well, in current solution we’d need to create a copy of john object before using setJohn to alter the state. In effect, we’ll get a new instance of the object in memory and john variable will hold a new reference (address) to it.

So, if we only change our onClick implementation to this one:

onClick={() => {
          const johnCopy = { ...john };
          johnCopy.age = john.age ＋ 1;
          setJohn(johnCopy);
        }}

Everything starts to work as expected:

I think you now understand how React state management works. I also hope that you see the issues managing state in such a way can bring. Even in this trivial example, we create a new instance of an object on every button click. Apart from memory usage considerations, this just looks ugly. Imagine manually creating copies of much more complex objects, like classes storing arrays or dictionaries. This gets pretty wild

We will see how this issue can be addressed by the end of this article. But first, let’s discuss props – another concept critical to really understand React state management.

Props

Apart from state, we also use props to control the state of our React components. The name is a short for properties, which quite well describes its purpose. Props are the data input provided to a component from outside (from a parent component). They are immutable and cannot be changed inside the component which receives them. Let’s see some examples.

Sharing state between components

The most common usage for props is sharing state between components. Imagine that you have an input, where the user manually enters some data. You want to use the current value of this input in two other components. This is where you need to share your component’s state (the value of the input) with these two other components. We often call it lifting the state up – you keep your state higher in the components tree, so the child components can use it.

Let’s try to see an example of connecting state with props:

export const PersonData = () => {
  const minimumAge = 5;
  const maximumAge = 100;
  const [age, setAge] = useState<number>(minimumAge);

  const handleAgeChange = (event: React.ChangeEvent<HTMLInputElement>) => {
    const enteredAge = parseInt(event.target.value);
    if (enteredAge >= minimumAge && enteredAge <= maximumAge) {
      setAge(enteredAge);
    }
  };

  return (
    <>
      <Form>
        <Form.Group controlId="age">
          <Form.Label>Your age</Form.Label>
          <Form.Control
            type="number"
            value={age}
            onChange={handleAgeChange}
            min={minimumAge}
            max={maximumAge}
          />
        </Form.Group>
      </Form>
      <DaysLiving currentAge={age} />
      <YearsUntilCentenarian currentAge={age} />
    </>
  );
};

As you can see, at lines 4 and 9 we manage the state variable age. This is the old stuff we have already seen.

However, at lines 27 and 28 we are passing the age state variable into DaysLiving and YearsUntilCentenarian children components as currentAge prop. This is how the DaysLiving component is implemented:

type DaysLivingProps = {
  currentAge: number;
};

export const DaysLiving = (props: DaysLivingProps) => {
  const daysLived = props.currentAge * 365;

  return (
    <div>
      <p>You have lived for {daysLived} days.</p>
    </div>
  );
};

Notice that props is simply a typed object you pass to a function component. To make things easier, you can also use object destructuring and accept the props in the following way:

export const DaysLiving = ({currentAge}: DaysLivingProps) => {
  const daysLived = currentAge * 365;
  /// ... rest of the code

That way, you don’t need to write props.currentAge every time you want to use this property inside the component.

Does changing props always trigger a re-render?

Well, generally the answer to this question is yes. Every time a prop of a component changes, this component will get re-rendered. However, this is not entirely true

To make this belief true, we need to assume that this prop is changed in a React way. So, to take things literally, consider this component we saw before:

export const DaysLiving = ({currentAge}: DaysLivingProps) => {
  const daysLived = currentAge * 365;

  return (
    <div>
      <p>You have lived for {daysLived} days.</p>
    </div>
  );
};

From its perspective only, it accepts a currentAge property. For this component to re-render, it’s not enough that the currentAge property changes in any way. Its value must be changed by mutating the state in the parent component.

So, if the value provided as currentAge to DaysLiving component changes in the parent component by properly mutating the state (with setAge mutation callback, in our case):

export const PersonData = () => {
  // ...
  const [age, setAge] = useState<number>(minimumAge);

  const handleAgeChange = (event: React.ChangeEvent<HTMLInputElement>) => {
      // ...
      setAge(enteredAge);
    }
  };

  return (
    <>
      // ...
      <DaysLiving currentAge={age} />
      // ...
    </>
  );
};

the child component (DaysLiving) will get re-rendered.

This is because when a parent component changes, React by default re-renders the parent component itself and all of its children.

If you modified the age variable in the parent compont directly, without using setAge (which we already know it’s incorrect), the currentAge prop would technically change, but the DaysLiving component will not get re-rendered.

state vs props

This is a question that people oftern ask: what’s the difference between props and state in React?

I would start with addressing this differently: what do props and state have in common?

As you already know, both are used for React state management. Both of them influence when the components will be re-rendered by React. Props and state are the absolute foundations of React.

The main difference is that state is used internally in a component, while props are used to pass information from parent to children components. State is also naturally mutable within a component where it’s defined, but props are immutable and cannot be changed in a component that receives and uses them.

React state management libraries

That’s basically everything you need to know to be able to comfortably work with React state management. However, I mentioned before that managing state using only built-in React mechanisms actually sucks That’s why I’d like to make a short point on state management libraries.

Maybe you heard about Redux, Zustand or MobX. All of them are state management libraires for React. But why would you even need one? And should you learn one now?

In my opinion, you can easily start working with React using the built-in state management mechanisms we discussed today. It’s good to know how it works in practice. However, the truth is that as your application grows and you want to keep it scalable and maintenable, you will need a state management library at some point. As soon as your components tree gets bigger, sharing data and state will not be as easy as “passing props to a children component”. You will need to share state between multiple components in the tree, sometimes not only between parent and children, but also with another components defined on the same level or even in a totally different place of the tree.

This is where React state management libraries come very handy. They solve many of the React’s issues that come to the surface as your state gets complex. But even if you use one, you will still always need state and props. That’s why it’s critical to understand these two basic concepts first and play with them for some time.

If you’re starting out, it’s good to know that state management libraries exist and that one day you will have to get your hands on one (or more ) of them. I hope to share my thoughts on state management libraries in a separate article one day.

Summary

That’s it! Now you should know how React manages state of its components. Of course, we didn’t cover everything related to state management in React, but I hope you got the basics

You can find all of the source code used in this article here.

How do you manage state in your React apps? Do you use a state management library? If yes, which one and why? Let me know in the comments below!

The post React State Management Basics appeared first on CodeJourney.net.

In this article, I will explain TypeScript compiler to you in simple terms. We will avoid complex stuff – only what you need for your everyday frontend developer’s work. We will not explore the inner workings of the TypeScript compiler Instead, we’ll see some practical implications of its workings for TypeScript developer. Let’s dive in

Few basic facts about TypeScript

For starters, let’s establish some quick facts about TypeScript as a language.

TypeScript is a superset of JavaScript

You may have heard that TypeScript is a superset of JavaScript. In other words, every JavaScript code is a valid TypeScript code. In case of TypeScript, being a “superset” means adding types information on top of perfectly legit JavaScript code.

Why is TypeScript only adding its types on top of JavaScript? In order to be able to remove them easily But why would it do that?!

Browser doesn’t understand TypeScript

The answer is that TypeScript cannot be run directly by a web browser (or NodeJS).

Let’s take this trivial TypeScript code:

let age : number = 27;

and try to paste it into Google Chrome’s console in order to execute it:

As you can see, it fails. The number type annotation is unknown to the browser. It means that before any TypeScript code is run in the browser, the information about types must be stripped out. In the end, browsers and NodeJS environments can only execute JavaScript. This is in short what TypeScript compiler does, and we’ll get into the details soon. For now, this leads us to another conclusion, that…

TypeScript is for developers

As we have just discovered, types must be removed by the TypeScript compiler before the code can be executed by the browser. In fact, this line of TypeScript:

let age : number = 27;

produces the following JavaScript output when processed by the TypeScript compiler:

var age = 27;

This is effectively the same code we wrote in TypeScript, but without type annotations.

Wrong data types assignments will only be detected at compile time:

but as soon as it’s compiled, this protection is not there anymore

This discovery means that TypeScript is for developers. Its job is to make our lives easier. Of course, in the end it also improves the end users’ experience, because programming in TypeScript is much better than using pure JS. But you can already see that TypeScript it not present at runtime at all. It only protects us until the compilation step by static types checking.

The philosophy is more or less as follows :

What’s worth mentioning, as the language’s specification says, “TypeScript never changes the runtime behavior of JavaScript code”.

TypeScript compiler in practice

tsc

TypeScript compiler is actually a CLI tool called tsc. It can be installed globally on your machine and used directly or built into your IDE. Refer to official documentation for installation details.

The compiler can also be installed locally in your project. It can then be set up as part of the build pipeline, which is supported by many bundlers. That’s why, when working on a TypeScript project, you may never encounter any direct usages of the tsc command.

tsconfig.json

In order to make working with TypeScript compiler easier, you should use a tsconfig.json file. It’s a JSON file containing all compilation settings. This is quite important, because, in opposite to C# or Java compilers, the TypeScript’s one allows for quite extensive (and flexible) configuration.

When you use the tsc command, it looks for tsconfig.json file in the current directory or any of the parent directories until it finds one. You can also provide a custom tsconfig.json location via --project parameter.

The simplest tsconfig.json file you get after initializing a new TypeScript project with tsc --init looks as follows:

{
  "compilerOptions": {
    "target": "es2016",
    "module": "commonjs",
    "forceConsistentCasingInFileNames": true,
    "strict": true,
    "skipLibCheck": true
  }
}

We will not explore all the individual settings in this article. The official documentation does a great job.

TypeScript compiler – example

Let’s now see how it works.

Having a bit more complex TypeScript file as an example:

class Person {
  private name: string;
  private age: number;

  constructor(name: string, age: number) {
    this.name = name;
    this.age = age;
  }

  public getName(): string {
    return this.name;
  }

  public getAge(): number {
    return this.age;
  }
}

const person = new Person("John", 27);
console.log(person.getName()); // Output: John
console.log(person.getAge()); // Output: 27

Notice the .ts extension. This tells the compiler that this file contains TypeScript code.

Having tsc installed globally, we can compile it by executing the following command:

tsc test.ts

For the file given above, the output of this command is the following JavaScript file:

var Person = /** @class */ (function () {
  function Person(name, age) {
    this.name = name;
    this.age = age;
  }
  Person.prototype.getName = function () {
    return this.name;
  };
  Person.prototype.getAge = function () {
    return this.age;
  };
  return Person;
})();
var person = new Person("John", 27);
console.log(person.getName()); // Output: John
console.log(person.getAge()); // Output: 27

Few things to note:

• there is no information about types in the .js file. As we discussed before, this is intentional – only pure JavaScript code can be understood by the browser
• notice there is no class keyword used in the compiled JS code, even though classes were introduced in ES2015. This is one of TypeScript compiler’s features – to produce code which is supported in most of the browsers and JS engines, without having to wait for support of new JavaScript versions
• comments are left untouched

This explains how the TypeScript compiler works. It also confirms what we stated before, that TypeScript is for programmers. As soon as your code is deployed to production, the types you added in .ts files are absent. The way this process is built gives a lot of advantages, but it may also be a source of confusion – let’s see how exactly.

TypeScript compilation flaws

Finally, knowing how TS -> JS compilation works, let’s quickly explore some of its common flaws.

No runtime protection

As you now know, TypeScript stripes out the types during compilation. It means that the information about types is not present at runtime (when our code executes). Because of that, we are not protected by TypeScript at runtime. Consequently, if an input comes from a user and the inputs themselves are not well validated, we may still get runtime type errors. Imagine that your code expects a number, but the user enters a string because of lack of proper input validation. TypeScript will not protect you here.

The same applies to validating API responses. Most data from HTTP APIs comes in a form of JSON. In TypeScript, we can represent such data as type or interface. Based on those expected shapes of data, we use objects of a given type and assume that given properties are present on them or not. However, APIs may change, and TypeScript will again not protect us at runtime. We still need to resort to alternative solutions for runtime types validation.

To be completely clear – I don’t think that no runtime protection is something TypeScript lacks. On the contrary – I love the flexibility of TypeScript which this approach gives. It’s just how the language has been designed, and we should be aware of that

Debugging complexity

When working on a TypeScript project, the code you see on production is different from the one in your IDE. Sometimes not only types are stripped out by TypeScript compiler, but as you saw earlier it may also convert some constructs to the other (like changing a class to a function). It makes debugging, especially directly on production, more complex.

In order to place breakpoints and actually have them hit in your TypeScript code, you need source maps. It does the job in most cases, but adds to the complexity at the same time, not always working seamlessly.

TypeScript is sometimes too strict

If you decide to migrate your JS project to TypeScript, you will quickly get frustrated by how strict this new language can be. Especially if you are coming from JavaScript world where everything is allowed

There are countless memes about that, but here is the one I like:

Joking apart, most things TypeScript complaints about can be configured/turned off in tsconfig.json file. This is actually what I like about TypeScript. It brings static typing into JavaScript world, but lets you control how strict you want it to be. So, if you get frustrated with TypeScript compiler’s complaints, remember about configuration options

Summary

I hope that now you feel more comfortable working with TypeScript compiler

If you’re a .NET developer, and you enjoyed this article, I think you may also find my free guide useful:

The post TypeScript Compiler Explained appeared first on CodeJourney.net.

If you’re starting your web development journey, or maybe have already dived into it, but are not really sure what JS bundlers are and what’s their role, you’re reading a proper piece of explanation

Chaos and complexity – the issues

Let’s consider a very simple JavaScript app. We have just one page index.html. Our HTML is hydrated with index.js file, which adds some interactivity to it. In order to use it, we need to import index.js script in index.html file. We also decided to use an external library (Bootstrap), so we should also link the necessary CSS.

We are linking the index.js with a script tag in head section:

<head>
    <script type="module" src="index.js"></script>
    <link
      href="https://cdn.jsdelivr.net/npm/bootstrap@5.2.3/dist/css/bootstrap.min.css"
      rel="stylesheet"
      integrity="sha384-rbsA2VBKQhggwzxH7pPCaAqO46MgnOM80zW1RWuH61DGLwZJEdK2Kadq2F9CUG65"
      crossorigin="anonymous"
    />
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>My WebPage</title>
  </head>

Of course, as we are building a web application, we won’t put all the JavaScript code in index.js. That’s why we created two separate files with some functionalities: my-utils.js and navigation.js.

For instance, the my-utils.js exports a few functions:

export function doSomethingNice() {
  alert("Nice!");
}

export function notUsedFunctionA() {
  alert("Not used function A");
}

export function notUsedFunctionB() {
  alert("Not used function B");
}

export function notUsedFunctionC() {
  alert("Not used function C");
}

Notice the not used functions there – we’ll get to the point of them soon.

Next, our index.js file imports what it needs and adds some interactivity to the HTML elements:

import { doSomethingNice } from "./my-utils.js";
import { reloadThePage } from "./navigation.js";

document
  .getElementById("reload-page-btn")
  .addEventListener("click", reloadThePage);

document
  .getElementById("say-sth-nice-btn")
  .addEventListener("click", doSomethingNice);

If we now open our webpage, we can see the network activity when the page is loaded:

Notice that all 3 JavaScript files are fetched separately: index.js, my-utils.js and navigation.js.

What’s more, if you check the contents of my-utils.js, it obviously loads the whole script, containing even the not used functions:

I think you might already feel that this can get a little problematic Imagine managing this when you have hundreds of your own JavaScript files plus dozens of external libraries. Not only will your app be making hundreds of network requests to fetch every single file, but it will always fetch everything – even the stuff your page doesn’t use.

Here’s where a JavaScript bundler comes into the field.

You can find full source code of this JavaScript app here.

What does a JavaScript bundler do?

JavaScript bundler produces bundles But what is a bundle? It’s basically a static file, optimized to be served to the client (in our case: a web browser). The main goal is to produce a single bundle file from multiple dependencies. In effect, the user’s browser doesn’t need to fetch so many files separately. But how is such a bundle created?

First, a JavaScript bundler needs to know the entry point. It’s a kind of root in which our “code tree” begins. In the case of our sample JavaScript application from the previous paragraph, a perfect candidate for an entry point would be the index.js file. Modern bundlers support multiple entry points. It can be very useful if you’re building a multipage application, so each page can have its own entry point.

The next step is to create a dependency graph. The JavaScript bundler is basically starting from the root (entry point) and traverses all dependencies referenced from it, as well as all of these dependencies’ dependencies. Having the dependency graph, bundler knows what is exactly used by what and in which place of our app.

This is how you can imagine the graph of dependencies:

Module bundlers like webpack not only know the dependencies of your entry point. These tools even check what each dependency uses. Thanks to building such a detailed dependency graph, the bundler can introduce multiple optimizations into the bundle file.

Finally, JavaScript bundler outputs the actual bundles. As I mentioned, bundles can be highly optimized by applying techniques like code splitting, CSS inlining, HMR and various performance optimizations.

JavaScript bundler might also ensure the backwards-compatibility with older web browsers by converting some newer JavaScript constructs used in your code to their equivalents from previous JS versions.

What’s interesting, modern bundlers can handle not only JS files, but also CSS, HTML and even images.

JavaScript bundler in action

Currently, the most popular JavaScript bundles is (still) webpack. It has been the first really advanced bundler created for both the browser and NodeJS.

You might have heard unpleasant things about webpack and in fact, its configuration can get really spaghetti There are simpler alternatives out there, but let’s start with what’s the most common tool used in web development today.

Adding webpack to a JavaScript app

Our sample app already has a package.json file (we used JavaScript modules), so we can install webpack with this command:

npm install --save-dev webpack webpack-cli

Now we should reorganize the files a bit. Let’s put all scripts in src folder and move index.html to dist folder. Finally, it looks like that:

Using the folder named dist is very common. It stands for distributable, which means the code ready to be distributed = served to the public. This is where our bundles will be located. As the index.html is directly served to the public, we also place it there.

With such a folders structure, there’s nothing more we need to configure for webpack to work. By default, webpack looks for src/index.js file which we already have and outputs bundles into the dist folder. To use more advanced features or multiple entry points, a configuration file should be added.

In our case, let’s go with the zero-config approach. The only thing we need is to add a script entry to package.json:

  "scripts": {
    "build": "webpack",
    "test": "echo \"Error: no test specified\" && exit 1"
  },

Let’s now run npm run build and see what happens:

It seems that webpack created the main.js asset (bundle):

Let’s make sure that our index.html page links this bundle file properly:

<!DOCTYPE html>
<html lang="en">
  <head>
    <script type="module" src="main.js"></script>

Now, let’s open our index.html page and see how the network requests look like now:

Wow, that’s something different from what we had previously! Notice that now only 1 script, the main.js file, is fetched by the webpage. There were 3 before: index.js, my-utils.js and navigation.js. Of course, the web page works exactly as before.

Let us also examine the contents of the fetched main.js file:

Pay attention what happened here. Webpack has nicely inlined all the external code we used directly into the main.js bundle. What’s more, the exported, but not used functions from my-utils.js are not present here at all! When building the dependency graph, webpack noticed that those functions are not used, so it didn’t include them

This is basically how webpack and most JavaScript bundlers work. Their role is to deliver the smallest and the most optimized bundles possible. This ultimately saves a lot of bandwidth by avoiding unnecessary network requests the client browser would otherwise need to make. Cutting out the unused code makes the bundles smaller, again reducing the network usage.

You can find full source code of the webpack app here.

Webpack has a lot more to offer

From all the JavaScript bundlers used today, webpack is the most advanced one. It’s the most mature one as well. It offers dozens of customizations, plugins and loaders. You can also easily add TypeScript support.

You can do really crazy stuff with webpack However, if you are starting your web development journey, don’t get overwhelmed by learning it all. Just be aware that webpack can do almost everything you might need. It’s just a matter of searching StackOverflow or asking Copilot

Alternatives to webpack

In recent years, developers created a few other amazing JavaScript bundlers. I recommend you to pay attention to them, because webpack doesn’t have to be your first choice today. Webpack is still used in CRA, which is believed to be a default way of creating new React applications. This is what makes it very widely used, but you don’t need to follow this path

I recommend checking Parcel, esbuild and ViteJS. These are modern bundlers created to, among others, eliminate some of webpack’s burdens. If you’re starting out and don’t want to get yourself busy with bundling configuration, I especially recommend creating your next app with Parcel.

Summary

That’s all that you need to know about JavaScript bundlers to be able to work with them and understand what’s happening when executing this magic npm run build script

If you’re a .NET developer, and you enjoyed this article, I think you may also find my free guide useful:

The post What Is A JavaScript Bundler? appeared first on CodeJourney.net.

Why?

You probably know what a wrapper is. As its name suggests, it’s a practice of putting another layer on a piece of something. In our case, wrapping a piece of code in another piece of code

But why would you do that? To make your life easier!
Wrapping external libraries lets you abstract your code from their implementation details. In effect, it makes your life a lot easier when you want to keep the behavior, but change the library providing it. This approach also lets you use only those features from a given external dependency that you actually need.
Let’s see that with an example.

Wrapping HTTP client

A very good example is HTTP client wrapper. HTTP calls are used in almost every web application. In order to perform them, we need to choose an HTTP client. We can either use fetch, or something more sophisticated like axios.

However, with time, we may decide to replace it with something else. There might be many reasons for that – either the library stops to be maintained or something new and better is out there. It would be a shame if we’d now need to change the code in those thousands of places where the current library is being used. This would take a lot of time and might be error-prone. We can definitely prepare better for such cases

Create HttpClient wrapper for axios

Let’s say that, for now, we will go with axios. Instead of calling it directly from our code:

import { useEffect, useState } from "react";
import axios from "axios";
import { Product } from "../types/product";
import { DummyJsonProductsResult } from "../types/dummyJsonProductsResult";

export const ProductsList = () => {
  const [products, setProducts] = useState<Product[] | null>(null);

  useEffect(() => {
    axios
      .get<DummyJsonProductsResult>("https://dummyjson.com/products")
      .then((result) => {
        setProducts(result.data.products);
      });
  }, []);
 
 // ...
};

I will create an HttpClient wrapper for it and use it instead.

First, I create httpClient.ts file in wrappers folder. I like to have such a catalog in my React projects and keep all the wrappers there.

I start writing all wrappers with an interface. In that case, I treat the interface as a contract. It should say what I need this small wrapper to do, without worrying about implementation details.

IHttpClient interface initially looks as follows:

interface IHttpClient {
  get<TResponse>(url: string): Promise<TResponse>;
}

That’s what we have so far. We just need to retrieve the data with GET method.

Next step is to create the actual implementation of IHttpClient using axios. This is pretty straightforward using a class implementing IHttpClient interface and taking a look at axios‘s documentation:

class AxiosHttpClient implements IHttpClient {
  private instance: AxiosInstance | null = null;

  private get axiosClient(): AxiosInstance {
    return this.instance ?? this.initAxiosClient();
  }

  private initAxiosClient() {
    return axios.create();
  }

  get<TResponse>(url: string): Promise<TResponse> {
    return new Promise<TResponse>((resolve, reject) => {
      this.axiosClient
        .get<TResponse, AxiosResponse<TResponse>>(url)
        .then((result) => {
          resolve(result.data);
        })
        .catch((error: Error | AxiosError) => {
          reject(error);
        });
    });
  }
}

This implementation lets us encapsulate a simple singleton inside the class.

The last step here is to expose the instance of our HTTP client. Remember to always export the interface type variable:

export const httpClient: IHttpClient = new AxiosHttpClient();

That’s basically how we wrap external libraries in TypeScript. Easy-peasy

Using the wrapper

I can now use our wrapper in ProductsList.tsx component:

import { useEffect, useState } from "react";
import { httpClient } from "../wrappers/httpClient"; // we don't import axios here anymore
import { Product } from "../types/product";
import { DummyJsonProductsResult } from "../types/dummyJsonProductsResult";

export const ProductsList = () => {
  const [products, setProducts] = useState<Product[] | null>(null);

  useEffect(() => {
    httpClient // instead of axios, we use our wrapper in components
      .get<DummyJsonProductsResult>("https://dummyjson.com/products")
      .then((result) => {
        setProducts(result.data.products);
      });
  }, []);
 
 // ...
};

Notice how easy that was. Since now, we only import stuff from axios package in httpClient.ts file. Only this single file is dependent on axios npm package. None of our components (and other project files) know about axios. Our IDE only knows that the wrapper is an object instance fulfilling IHttpClient contract:

Extra wrapper features

Apart from nicely isolating us from dependencies, wrappers have more advantages. One of them is a possibility to configure the library in a single place. In our example with axios – imagine that one day you want to add custom headers to each HTTP request. Having all API calls going via AxiosHttpClient, you can configure such things there, in a single place. That way, you follow the DRY principle and keep all the logic related to axios (or to any other external dependency) in a single place. It also comes with benefits like easy testability etc.

For clarity, I also added post support to our IHttpClient. You can check it here.

Replacing the wrapped library

Ok, it’s time to have our solution battle-tested. We have the HTTP client nicely wrapped and exposed as an instance of IHttpClient. However, we came to the conclusion that axios is not good enough, and we want to have it replaced with fetch.

Remember that in the real web application, you would have hundreds or thousands of usages of IHttpClient instance. That’s where the power of wrappers comes into play

So how do I make sure those thousands of usages will now use fetch instead of axios? That’s actually pretty straightforward. I’ll simply add a new class – FetchHttpClient implementing IHttpClient interface:

class FetchHttpClient implements IHttpClient {
  get<TResponse>(url: string): Promise<TResponse> {
    return new Promise<TResponse>((resolve, reject) => {
      fetch(url)
        .then((response) =>
          response
            .json()
            .then((responseJson) => {
              resolve(responseJson as TResponse);
            })
            .catch((error: Error) => {
              reject(`Response JSON parsing error: ${error}`);
            })
        )
        .catch((error: Error) => {
          reject(error);
        });
    });
  }

  post<TResponse>(url: string, data?: object): Promise<TResponse> {
    return new Promise<TResponse>((resolve, reject) => {
      fetch(url, {
        method: "POST",
        headers: {
          "Content-Type": "application/json",
        },
        body: JSON.stringify(data),
      })
        .then((response) =>
          response
            .json()
            .then((responseJson) => {
              resolve(responseJson as TResponse);
            })
            .catch((error: Error) => {
              reject(`Response JSON parsing error: ${error}`);
            })
        )
        .catch((error: Error) => {
          reject(error);
        });
    });
  }
}

For completion, I included POST here as well.

The one last thing I have to do to make our new FetchHttpClient be used in the whole app in place of AxiosHttpClient is to change a single line with export:

export const httpClient: IHttpClient = new FetchHttpClient(); // instead of new AxiosHttpClient()

and that’s it! Our whole application now uses fetch for GET and POST HTTP requests And it even still works

Summary and source code

I hope that now you see how important it is to wrap external libraries. We have seen that on JavaScript/TypeScript app example, but this is applicable to any programming language and framework.

It’s always good to be as independent as possible of 3rd party stuff. Too many times I’ve been in a situation that some npm package is so extensively used in a project, directly in the source code in hundreds of places, that it cannot be replaced without spending several days on it. Creating wrappers forces us to think abstract, which is another great advantage.

You can find the complete source code here: https://github.com/dsibinski/codejourney/tree/main/wrapping-external-libraries

The post How (And Why?) To Wrap External Libraries? appeared first on CodeJourney.net.

After reading this article, you will know how to add such a menu to your React app. The end result will look as in the highlighted picture of this article

Creating a table with row selection support

First, let’s define a type of data that we want to display. For our example, we will display a list of Cars:

export type Car = {
  id: string;
  brand: string;
  model: string;
  productionYear: number;
  isAvailable: boolean;
};

Next, we create a new component called CarsTable, responsible for rendering the table. We will use @tanstack/react-table for the table behavior and react-bootstrap for UI elements.

I implemented the CarsTable component in quite a standard way according to react-table docs, so I won’t copy-paste it here. You can check the whole component’s code here. What’s interesting is that I added support for row selection in a way that makes our table a controlled React component:

type CarsTableProps = {
  selectedCar: Car | null;
  onCarSelected: (car: Car) => void;
};
export const CarsTable = (props: CarsTableProps) => {
  return (
    // ...
    <tbody>
        {table.getRowModel().rows.map((row) => {
          const isActive = row.original.id === props.selectedCar?.id;
          return (
            <tr
              key={row.id}
              style={isActive === true ? { backgroundColor: "#3a7a11" } : undefined}
              onClick={() => {
                props.onCarSelected(row.original);
              }}
            >
              {row.getVisibleCells().map((cell) => (
                <td key={cell.id}>
                  {flexRender(cell.column.columnDef.cell, cell.getContext())}
                </td>
              ))}
            </tr>
          );
        })}
      </tbody>
    // ...
  )
}

As you can see, selectedCar and onCarSelected are managed from outside. Line 14 shows how the row color gets changed for the currently selected car. I recently had to deal with such a case in one of my projects.

So far, so good. This is how it looks, populated with sample data:

Adding meatballs menu

Ok, we have a table. Now we want to add the meatballs menu. We need a three dots icon and a dropdown menu to open on clicking it.

After quickly going through the react-bootstrap docs, let’s create a new component for that:

import { Dropdown } from "react-bootstrap";
import { Car } from "../types/Car";
import CustomDivToggle from "./CustomDivToggle";
import { BsThreeDots } from "react-icons/bs";

export const CarRowContextMenu = ({ carRow }: { carRow: Car }) => {
  return (
    <Dropdown key={carRow.id}>
      <Dropdown.Toggle as={CustomDivToggle} style={{ cursor: "pointer" }}>
        <BsThreeDots />
      </Dropdown.Toggle>
      <Dropdown.Menu>
        <Dropdown.Item>Option 1</Dropdown.Item>
        <Dropdown.Item>Option 2</Dropdown.Item>
      </Dropdown.Menu>
    </Dropdown>
  );
};

As we want our dropdown toggle to have custom style, I had to provide CustomDivToggle as a custom dropdown component. It’s nothing very interesting, but you can check its implementation here

Next, as we’d like our meatballs menu to be an additional column in the grid, it seems natural to use react-table‘s display column. Let’s try adding it:

columnHelper.display({
      id: "context-menu",
      cell: (cellContext) => {
        const row = cellContext.row.original;
        return <CarRowContextMenu carRow={row} />;
      },
    }),

It looks we have it:

However, after clicking through it for a while, it seems we have an issue. The toggle only opens on every 2nd click:

Why is that? The reason is our controlled CarsTable component. On clicking a new row, the change event occurs, which triggers the re-render of the CarsTable component (because selectedCar actually changes). It makes react-table re-render the table, with the meatballs menu in its default state (collapsed). On clicking the menu in the same row again, the change event occurs, but the selectedCar does not actually change, which does not trigger the re-render. Initially, it took me a while to figure that out

Fixing double-click issue

In our case, a fix for the double click issue is quite simple. Instead of adding the column with the menu using columnHelper.display() function from react-table, we can render it manually. To do that, we should simply add a new <td> to each row of the table:

<tbody>
        {table.getRowModel().rows.map((row) => {
          const isActive = row.original.id === props.selectedCar?.id;
          return (
            <tr
              key={row.id}
              style={isActive === true ? { backgroundColor: "#3a7a11" } : undefined}
              onClick={() => {
                props.onCarSelected(row.original);
              }}
            >
              {row.getVisibleCells().map((cell) => (
                <td key={cell.id}>
                  {flexRender(cell.column.columnDef.cell, cell.getContext())}
                </td>
              ))}
              <td>
                <CarRowContextMenu carRow={row.original} />
              </td>
            </tr>
          );
        })}
</tbody>

Additionally, to make it work, we need an additional table’s header placeholder:

<thead>
        {table.getHeaderGroups().map((headerGroup) => (
          <tr key={headerGroup.id}>
            {headerGroup.headers.map((header) => (
              <th key={header.id}>
                {header.isPlaceholder
                  ? null
                  : flexRender(
                      header.column.columnDef.header,
                      header.getContext()
                    )}
              </th>
            ))}
            {/* placeholder header for context menu */}
            <th></th>
          </tr>
        ))}
</thead>

That’s it! Our `react-table` table with row selection support and the meatballs menu works like a charm now:

Meatballs menu with react-table – source code

You can find the complete source code here. I hope you find it useful!

The post Adding Meatballs Menu To React-Table Rows appeared first on CodeJourney.net.

Prettier

My number one. I was a bit skeptical initially, but today I can’t imagine my life without Prettier For those unfamiliar with the tool, Prettier is an opinionated code formatted. Opinionated, because it allows for almost no configuration. It reformats your code automatically based on its own rules.

It may sound scary and limiting, but it really frees your mind. Suddenly you forget about all those spaces vs tabs wars and discussions on which column shall the code be wrapped. Prettier does that all automatically. It can even be done on saving the file! Just take a look, how beautiful that is:

It is also very easy to execute prettier formatting with pre-commit git hook, so the checked-in code is always formatted, even if some team members don’t use it in their IDE.

Never again without Prettier!

ES7+ React/Redux/React-Native snippets

This is one of the first VS Code extensions I installed. It’s simple, yet very powerful! This plugin adds multiple JavaScript/React snippets. I create many new components every day. Snippets make it very easy:

I recommend trying this extension out and exploring its built-in snippets.

C# to TypeScript

This one is a time-saver for .NET developers working with TypeScript. It allows generating TypeScript interfaces from C# classes. You can simply copy a C# class and paste is as a TypeScript’s interface in Visual Studio Code:

You can also paste using keyboard shortcuts. There’s even a CLI tool available in case you’d want to automate this process. This extension doesn’t support all scenarios (especially no support for records ), but it still covers most simple copy-paste cases. By the way, synchronizing C# with TypeScript types is one of the challenges for full stack .NET developers.

Total TypeScript

From all VS Code extensions I use, this is the only one that actually helps me learn on the job. It was called TypeScript Error Translator before, and this is what I initially used it for. It basically provides more meaningful, crowdsourced translations for often enigmatic TypeScript errors:

When a translation is missing, you can always contribute one. Additionally, as its new name suggests, it also lets you learn programming concepts directly inside your code. As soon as it finds a new concept in the code, a brief explanation is shown:

It will stop highlighting this particular type of concept as soon as you mark it as learned. I think it’s a quite interesting way of learning on the job

ESLint

This is the extension for integrating the most well-known linter for JavaScript into Visual Studio Code. ESLint is a static analyzer of your source code which helps you find problems quickly. It will highlight issues in your code for all loaded files from your workspace. I don’t feel there’s much to write about here – just check their website and give this extension a try

Thunder Client

Thunder Client is like Postman, but built into VS Code. It lets you easily play with HTTP APIs. You can create your own collections of requests and export them to JSON, which can be checked into the source control.

Yet another very useful extension!

Preview.js

This is one of my recent discoveries. Preview.js allows to live-preview React, Solid or Vue components directly in VS Code. It also generates the initial props data, sometimes even for complex objects:

The plugin is also configurable for custom scenarios like external dependencies. You can find more information in the documentation.

WakaTime

If you like analytics, you should check this VS Code extension. WakaTime measures how much time you spend actually writing code. It shows exactly in which language you programmed for how much time. It also divides time entries into projects you worked on:

It’s interesting to get such insights “for free” and see how little time we spend actually coding Try it for yourself and let me know your results!

One Dark Pro

Who never started a new project by installing fancy tools, text editors or choosing the best color theme for your IDE? Of course – good colors = smooth -and pleasant – coding One Dark Pro is a must-have theme for my Visual Studio Code. I love it, it makes source code much more readable for me. What’s your favorite color theme for VS Code?

vscode-icons

Last but not least, a good friend to the One Dard Pro theme, legendary VS Code icons set. It has over 13M installs!

Apart from getting +100 to fanciness , it makes icons more explicit in the explorer:

As you can see, it even guesses the folder type based on its name – see types or utils folders’ icons above.

Not critical, yet helpful. Undeniably adds a million to your professionalism as a web developer

Summary

So, that’s it! The list of my 10 favorite Visual Studio Code extensions.

What about you? What are your must-have VS Code extensions?

The post 10 VS Code Extensions I Couldn’t Live Without appeared first on CodeJourney.net.

The symptoms of this issue are putting your mouse on something where you’d expect the IntelliSense guidelines, but instead you only see the “Loading…” text.

In this short article, I’m sharing the reason of this issue and my way of fixing it.

How VS Code Infinite IntelliSense Loading Looks Like

This is what I struggled with:

As you can see, I didn’t get any IntelliSense while hovering my mouse on various elements in the editor.

A similar thing happened when I tried to use Go to References (or Shift + F12 on Windows) for any object:

As you can see, the loading bar at the top of VS Code was showing progress infinitely.

Let’s now see how to fix this annoying issue

Fixing Visual Studio Code IntelliSense Loading Infinitely

After quite long investigation, I finally found the reason. It turned out that sometimes your Visual Studio Code might be using a different TypeScript version than your workspace uses. In my case, it was exactly the cause of the infinite loading problem

In order to fix it, use TypeScript: Select TypeScript Version... command. You can access commands with Ctrl + Shift + P on Windows or ⇧⌘P on Mac:

Select this command and tell Visual Studio Code to use the workspace version of TypeScript:

As you can see on the screenshot above, in my case the VS Code’s TypeScript version was 4.8.2, while the workspace version was 4.8.3. Changing it to use the newer, workspace version solved the problem. Visual Studio Code IntelliSense loading infinitely issue was gone

If it doesn’t work straightaway, you might need restarting your VS Code editor.

I hope that worked for you and saved you some hours of debugging and exploring StackOverflow

The post How To Fix Visual Studio Code IntelliSense Loading Infinitely appeared first on CodeJourney.net.

If you ever had an API action defined like that in your controller:

and fetched this data using TypeScript in the following way:

at some point, you probably also experienced the desynchronization of backend (C#, in our example) and frontend (TypeScript) types definitions. What if someone has changed the C# version of UserViewModel, but no one corrected its TypeScript’s equivalent?

Your TypeScript fetching code will tell nothing about that. There will be no error, even though the fetched data doesn’t match the expected UserViewModel type.

I’ll try to address this issue in this article Let’s see how typing API responses with zod can help us here.

Synchronization of Backend and Frontend API Typings

First, why would we want to keep the backend and frontend models in sync?

For me, that’s the purpose of using TypeScript. We want our code to be as well-typed as possible. For instance, we normally want the data displayed to the user to be fully typed. TypeScript enhances our programming experience by providing us with typing information. Thanks to that, we know what is what and what contains what. We also express what types of data we expect in particular cases.

The APIs mostly return JSON data, which can be anything. Because of that, it is much easier to have the data returned from the API fully typed in TypeScript. Thanks to that, we know what properties are available on the data models received from the API and whether we can use and display them to the users.

The sample code used within this article is available on GitHub. We will use ASP.NET Core (C#) and React (TypeScript) apps as examples.

Models synchronization example

As we saw in the beginning, a classic example is an API controller that returns a strongly-typed data:

The returned data type is a collection of UserViewModel objects. Here’s the C# definition of this type:

Its equivalent is also defined on TypeScript side:

Usage in TypeScript

Cool. With this simple code, we can create a usersService.ts file and fetch our users’ data from the API. Notice how we make this call strongly typed:

Everything looks legit. We can use the data retrieved from the API in UsersList component and everything is nicely typed:

The data is even perfectly displayed:

So, what can go wrong here?

The Problem – Typings’ Desynchronization

Let’s say that a backend developer implements a requirement to rename “loyalty points” into “fidelity points”. Easy. (S)he renames LoyaltyPoints property in the C#’s UserViewModel to FidelityPoints.

The new C# model looks as follows:

Nice! The backend dev is a very good programmer, so (s)he even launches the React web application to make sure that everything still works correctly and there are no errors in the dev console:

After a quick look, everything looks awesome. The users list is displayed, there are no errors in the console. Apparently, these test users don’t have any loyalty points assigned – that’s why the empty values in “Loyalty points” column. What’s more, translators will update the column’s translation later. We are good! Let’s go on prod!

I guess you already know what went wrong here. API definition changed, but TypeScript didn’t inform us about that Our UserViewModel still uses the old property name:

However, it still works. When rendering the UsersList, we simply get undefined in place of loyaltyPoints:

In the end, this is all JavaScript there. What’s interesting, the renamed fidelityPoints property is already there at runtime:

but no one cared about it

With the current solution, we will never be informed soon enough about API models changes in our React application. In the best case, we’ll get an undefiend or null error when clicking through the app. However, it’s usually an end user who finds such problems on production. This is definitely not what we want

We can solve this problem by typing API responses with zod. Let’s now see how to do that.

The Solution – zod

Our remedy – zod – is quite a decent npm package with with ~600k weekly downloads. Its GitHub page advertises the library as TypeScript-first schema validation with static type inference.

You can definitely do many things with zod. It can be used together with libraries like react-hook-form to perform complex forms validation. However, in our case, we’ll treat zod as a solution for better typings in TypeScript.

Adding zod to React app

First, let’s install zod into our React application:

npm i zod

First schema definition with zod

With zod, we define our types in a slightly different way. Instead of creating a type or interface directly, we first create a schema. In our case, we can define a UserViewModelSchema using z.object creator function:

Few interesting parts here:

• Line 2: notice how zod helps us to define types like Guid with built-in schemas like uuid()
• Line 8: first, I used AddressViewModelSchema here. This is a custom schema of an AddressViewModel object, which is another type used internally in UserViewModel. You can use such custom schemas in other schemas. Also notice the nullable() call here, which makes the address property nullable

First step done – we have our UserViewModelSchema. But can we use it instead of UserViewModel type? Not really. Schema is used for validation purposes only. We still need the UserViewModel TypeScript’s type.

Inferring type from zod’s schema

Fortunately, zod comes with a handy z.infer function that allows us to infer the type from the schema.

Finally, the userViewModel.ts file looks as follows:

We can use the exported UserViewModel type as previously used type. It’s an equivalent, inferred from UserViewModelSchema.

Validating API responses with zod schema

One last step is to make use of UserViewModelSchema. Let’s modify the getAllUsers function from usersService to validate the data received from the API against our schema:

Notice the usage of z.array. This function call tells zod to validate an array of objects meeting the rules defined by UserViewModelSchema, not a single object.

Now, let’s run our React app and see what happens when we click the “Fetch users” button:

This is awesome! Exactly what we wanted – a schema validation error for API response. Notice how the error message precisely points to the missing (or wrong, in other cases) property. It tells us we expected a number called loyaltyPoints, but instead we received undefined. The reason for this error message is that the loyaltyPoints field is Required in our schema.

After renaming loyaltyPoints to fidelityPoints in UserViewModelSchema and updating the UsersList component accordingly, everything works fine again.

We are now fully typed and prepared for the future, in case an issue with desynchronization of frontend and backend typings happens again

Summary

Today, we’ve seen how typing API responses with zod can help us detect frontend and backend models desynchronization. Schema validation throws errors when the data doesn’t match its expected shape.

Remember that zod is an extended library with many options. I recommend exploring them on your own. An interesting feature we didn’t cover in this article is strict mode, which doesn’t allow additional fields not present in the schema definition when validating the data object.

The open question remains whether to use schema validation on production. One could think that it’s better to not throw any validation errors, because JavaScript may just work. However, I think that throwing an error is always better than silently letting things through. An error lets programmers, automated tests or manual testers to detect the issue before the end user does

You can explore the complete code presented in this article here.

The post Typing API Responses With Zod appeared first on CodeJourney.net.

The title picture of this article shows the end result. If you want to know the solution, keep reading

Context

The context of this need is very simple. I have a unit test in which I want to perform some operations and keep the test running indefinitely afterwards. The use case might be instantiation of an in-memory test server. After that, I want to inform the user (programmer or the one running the test) that the server is up and running. I want to do that before the test finishes. In other words: I want to write the test’s output while it’s still running.

In my case, I was running two .NET Core apps in-memory. The backend server app and the ASP.NET Core web application. In the process, the web app got its IP address assigned dynamically. Meaning that the IP was different with each test run. This particular test was used to run the app in-memory and let the user manually use the application. It means the user must know the IP/URL of the in-memory web app. That’s why I needed to output the dynamic IP address into the NUnit test output

Solution

The solution to write test progress to the console with NUnit is very simple. To do that, use TestContext.Progress.WriteLine(string) method from NUnit.Framework namespace:

And that’s it! I’m publishing this simple solution, because it took me some time to find

I previously tried with TestContext.Out.WriteLine, System.Diagnostics.Trace.WriteLine and System.Console.WriteLine, but all of them output the text after the test finishes.

Finally, you can also run the test from cmd using dotnet test:

Hope it’s useful!

The post Write Test Progress To The Console With NUnit appeared first on CodeJourney.net.

NHibernate.Exceptions.GenericADOException: could not load an entity: 
...
 ---> Microsoft.Data.SqlClient.SqlException (0x80131904): Database 'myappdb' on server 'myapp.database.windows.net' is not currently available.  Please retry the connection later.  If the problem persists, contact customer support, and provide them the session tracing ID of '{EB501CF2-2F21-4E28-9042-2B83EEE57B91}'.

The database is not currently available was very interesting to me. I struggled a bit with solving that, so if you want to know how I did it – continue reading

The problem

My .NET 6 app is an Azure App Service, and it uses SQL Server database. Quite standard Azure stuff.

The issue was that when opening the ASP.NET web app after some time of inactivity, there was an HTTP 500 error. When I checked the logs, the full error looked as follows:

NHibernate.Exceptions.GenericADOException: could not load an entity: [MyApp.Infrastructure.DomainObjects.ApplicationUser#37931c5a376748d7a49f215ca30283a2][SQL: SELECT applicatio0_.applicationuser_key as id1_3_0_, applicatio0_1_.UserName as username2_3_0_, applicatio0_1_.NormalizedUserName as normalizedusername3_3_0_, applicatio0_1_.Email as email4_3_0_, applicatio0_1_.NormalizedEmail as normalizedemail5_3_0_, applicatio0_1_.EmailConfirmed as emailconfirmed6_3_0_, applicatio0_1_.PhoneNumber as phonenumber7_3_0_, applicatio0_1_.PhoneNumberConfirmed as phonenumberconfirmed8_3_0_, applicatio0_1_.LockoutEnabled as lockoutenabled9_3_0_, applicatio0_1_.LockoutEnd as lockoutend10_3_0_, applicatio0_1_.AccessFailedCount as accessfailedcount11_3_0_, applicatio0_1_.ConcurrencyStamp as concurrencystamp12_3_0_, applicatio0_1_.PasswordHash as passwordhash13_3_0_, applicatio0_1_.TwoFactorEnabled as twofactorenabled14_3_0_, applicatio0_1_.SecurityStamp as securitystamp15_3_0_ FROM ApplicationUsers applicatio0_ inner join dbo.AspNetUsers applicatio0_1_ on applicatio0_.applicationuser_key=applicatio0_1_.Id WHERE applicatio0_.applicationuser_key=?]
 ---> Microsoft.Data.SqlClient.SqlException (0x80131904): Database 'myappdb' on server 'myapp.database.windows.net' is not currently available.  Please retry the connection later.  If the problem persists, contact customer support, and provide them the session tracing ID of '{EB501CF2-2F21-4E28-2342-2B836E35E891}'.
   at Microsoft.Data.ProviderBase.DbConnectionPool.CheckPoolBlockingPeriod(Exception e)

There were two characteristics of this error:

• it always appeared after some time of not using the web app
• I never reproduced it locally

So it must have been something wrong with Azure.

Transient issues in Azure databases

First thing I did, obviously, was checking Azure App Service logs. This is what I found:

The first recommended step got me curious. To reduce the impact of connection issues caused by future reconfiguration, please implement retry logic in your code.

So I started reading. There’s even official Microsoft documentation for that. It basically says that in the cloud environment you’ll find that failed and dropped database connections happen periodically.

I must admit it seemed quite new to me. However, I started digging into that. I used Polly to implement the retry logic in my app. I found few places where there was an NHibernate query for fetching users executed and wrapped it into the retry policy.

Nothing worked. I was still getting the error. Then, after some talks with my coworkers, we found the real reason behind that…

Solution: Azure database tier

When talking about the issue with my teammates, someone mentioned that the databases in Azure are serverless by default.

I logged into the Azure Portal and checked the “Compute + storage” settings my SQL database my app used:

Indeed, the tier selected was “General purpose (Scalable compute and storage options)” with “Serverless” compute tier selected.

I changed it to “Basic (For less demanding workloads)”:

and… it worked All errors saying that the database is not currently available disappeared. I also removed all Polly-related code for retry policies.

A little explanation

Why do serverless databases in Azure behave like that?

I finally found this explanation in the Microsoft documentation:

If a serverless database is paused, then the first login will resume the database and return an error stating that the database is unavailable with error code 40613. Once the database is resumed, the login must be retried to establish connectivity

That blew my mind! It means that the database is not currently available exception is expected. There’s also another part there:

Database clients with connection retry logic should not need to be modified. For connection retry logic options that are built-in to the SqlClient driver, see configurable retry logic in SqlClient.

Apparently, users of ORMs like Entity Framework should not have to worry about those issues. Unfortunately, NHibernate doesn’t have such built-in transient errors retry logic. That’s why I experienced this particular issue and couldn’t find any straightforward solution online. Simply not many people (if anyone at all? ) experienced this before.

If you want even more details and context, check out this article: SHOULD I USE SERVERLESS FOR ALL MY AZURE SQL DATABASES?

What if I want to use serverless Azure database?

Well… if you really want to use the serverless features of Azure, you might be struggling with NHibernate. As I mentioned, apparently there’s no built-in transient failures retry mechanism in the ORM. There’s one promising solution here. However, currently it’s build for NHibernate 3.3.1.4000, so it doesn’t work with the current version. There’s a Pull Request and an issue opened for upgrading it to the newest version and .NET 6/7. Let’s hope it is done soon.

Otherwise, you can try using Polly as I did initially. However, I didn’t manage to make fully working.

If you have any other idea or solution – let us know in the comments below.

Conclusion

I hope this article saves you some hours of debugging, so you can quickly solve this database is not currently available error in Azure. I wish I found this article on another website few weeks ago

The post How To Fix SqlException Database Is Not Currently Available On Azure (0x80131904) appeared first on CodeJourney.net.

Finally, I found a solution and a reason for that issue.

The error occurred when I was trying to install @testing-library/react npm package. It looked like that:

Hotfix

If you ever get this error, the hotfix is to follow these steps:

• delete node-modules folder
• run command npm cache clean --force
• run command npm install
• install the package again with npm install your-package-name

It should all work fine after that.

If these commands still don’t solve your issue, and you use git as a source control system, you can try the unbeatable git clean -fdx command. After that, run npm install again. Beware – it removes all files not checked in to git. It may also remove your IDE settings etc., so use with care.

But it’s only a hotfix, a solution for now to unblock you.

Coldfix (solution)

The real reason for this issue in my case turned out to be related to jest. However, not to the testing library itself, but to jest extension for Visual Studio Code.

The reason for the issue is the jest tests runner working in the background. You can see that in the VS Code bottom bar:

The real solution is to disable jest runner when installing new packages. You can do it with a Jest: Stop Runner command in Ctrl+Shift+P:

I don’t know exactly why this is an issue. I guess jest runner is blocking some files in node-modules, so they cannot be renamed/processed. I hope it helps you too

The post How to fix: npm ERR! enoent ENOENT: no such file or directory, rename appeared first on CodeJourney.net.

The Asserts Hell

Let’s consider the following unit test:

What’s wrong here? Given and When sections are great single-liners. We know straightaway what’s the input and the action executed. However, Then block is too complex. It’s hard to figure out, just passing quickly through this test, what is expected. This case is even not that bad thanks to the usage of FluentAssertions.

I spend a lot of time writing tests (unit or integration), but I spend even more time reading them. I always hope that I will find these idyllic tests that act as code documentation…

However, let’s go step by step. I recently took place in a software testing course. That’s where I discovered the solution to The Asserts Hell.

Assert Object for Better Asserts

Assert Object pattern is what solves our problem. The idea is to create an Assert class which wraps the original object being tested. In our case the tested object is of Product class, so our assert class will be called ProductAssert.

Let’s see the implementation:

As you can see, we simply moved the asserts from our test’s Then section into ProductAssert class’s methods. Additionally, we always return this from each asserting method, which allows chaining functions calls.

We can now use such assert object in our unit test:

You must agree it’s much more readable now

We can of course improve it even more, for example by wrapping these 3 assertion methods (BeAvailable(), HaveDiscount() and Cost()) into a single one. We can also easily create an extension method for the Product class itself, so the assert object doesn’t have to be instantiated in our unit test. I could even add an extension to FluentAssertions library.

You can find complete source code used as examples in this article here.

Assert Object – summary

I personally find Assert Object a very useful tests code refactoring method. As a programmer, you spend most of your time not on writing, but on reading the source code. Clear and simple tests can make your (and your colleagues’) life much better

Of course, the Assert Object pattern should not be your default way of asserting. If you can complete your test with one or two assertions, then it’s probably better to keep it without wrapping into any additional objects. Having too many assert statements might also mean that the objects being tested are poorly designed. However, as we often work with legacy code which we can’t easily change or refactor, it might be a good solution.

What patterns for writing better tests do you use? Share your tips in the comments!

The post Improve your tests with Assert Object Pattern appeared first on CodeJourney.net.

Today I can say that it was the best decision we could make. TypeScript makes working with JavaScript, which is sometimes surprising and quite hard to understand, so much better experience. However, there were some challenges on this journey. If you want to know what issues we met and how we solved them, but also what huge advantages TypeScript gave us – read on

I will not discuss TypeScript itself in this article. This is a pure recap of challenges and the experience I gained when migrating to TypeScript.

Choosing migration strategy

Before starting migrating to TypeScript, we had to choose the best strategy for this process. There were two possibilities we considered: migrating the whole JavaScript codebase to TypeScript at once or switching to TypeScript compiler and migrating part-by-part.

For those who are not familiar with TypeScript – it is a superset of JavaScript which adds typing information to your JS code. It means that every JavaScript code is also a valid TypeScript code. When compiling TypeScript code, TS compiler removes the typing data and outputs readable, vanilla JavaScript code ready to be executed.

Migrating the whole codebase to TypeScript would mean to change all files extensions to TypeScript ones: .js to .ts and .jsx to .tsx. It would also mean that TypeScript compiler starts checking types in those files. This approach is doable, but – depending on the size of your project – can take a long time. During migration the code would be frozen until you fully migrate the project. Also, for TypeScript beginners, it could be a bit frustrating having to type everything at once or use some tricks to tell TypeScript to ignore checking types in many cases (because the type is not known at this stage, or we want to do it later etc.).

Because of that, we decided to migrate part-by-part, having JavaScript and TypeScript files at the same time. It is possible thanks to enabling allowJs TS compiler option. It means that TypeScript will compile both TS and JS files. Such approach allows the coexistence of old JS code with the new TS parts. It also allows moving only chosen parts of the application to TypeScript at the beginning and come back to the others later.

In our web application the biggest JS files have few thousand lines of code. Some of this legacy code still didn’t use React, but Backbone as their framework. We didn’t want to touch these oldest files in the beginning. Instead, we moved few recently written functionalities to TypeScript straightaway and decided to implement everything new in TS as well.

Bright side of migrating to TypeScript

If you are a JavaScript developer, the best advice I can give you is to start using TypeScript In this section I’m describing what positively surprised me since the beginning of starting to use TypeScript.

Types “for free”

As soon as we changed our transpiler from babel-loader to ts-loader, I wanted to know how we can get typing information for already-installed npm packages. It turns out that for 98% of the packages we used there’s already a typing information available as a separate npm package.

In most cases if you have a npm package called abc there’s a typing package available called @types/abc. I explored our package.json and for each package listed there I just executed npm install @types/package-name. 2 or 3 older or not-so-popular packages didn’t have types definitions available, but for the rest we got types for free, without having to type anything ourselves. This was a first, very nice surprise

You can find more information about TypeScript types definition packages, as well as contribute one yourself, here.

All new code is typed

As I wrote before, every new feature we’ve added since the migration is written in TypeScript. Thanks to that, all new code we write is strongly typed. What’s remarkable here is that it required almost no effort. We just switched the compiler to TS (with a small struggle with webpack configuration, about which you can read below) and suddenly got into typed world for every new feature we implement. Quite impressive, isn’t it?

JS-TS friendship

Coexistence and friendship between JavaScript and TypeScript is HUGE. These two creatures are not enemies – they are best friends We’ve already gone through many scenarios when we needed to use something written in TS in a JS file and otherwise. It turns out that all of these scenarios are manageable. Sometimes you need to import something differently (for example using require instead of import), but it’s all possible. We found it super easy to write new features or even add parts of new features to already-existing JS code, writing everything in TypeScript.

We also rewrote some JS files that were used from multiple places in the app to TypeScript. As an example of JS-TS coexistence, I’m presenting below the potential .ts source code you might have. It contains both old, legacy JS code when we used module.exports and prototype to expose various services for data fetching, as well as a brand-new, nicely-exported TypeScript class:

Such code can of course be in separate files, but it only shows how good TS and JS can coexist together. You can keep your old code working, while implementing anything new in TypeScript.

Flexibility in partial migrating to TypeScript

It turns out that choosing to partially move our web project to TypeScript was a great decision. The team wouldn’t be so happy and enthusiastic about TS if we told them to move legacy Backbone code to TypeScript. Instead, we gave them a nice tool which can be used for all new stuff. Also, if someone likes the idea and wants to move already-existing JS file to TS, he or she is welcome to do so.

That’s how we are still migrating our project to TypeScript, without any hustle and frustration

Wisdom of TypeScript

I’m positively surprised by TypeScript almost every day. At some point I get to the issue that seems hard to be solved or quite non-standard. Then I find a solution online and it makes me really impressed about the job the community and Microsoft has been doing around the language.

These are sometimes small, but smart things. Recently we got surprised by keyof, which lets you get names of the allowed properties of your type. Generally the typing system is really advanced and impressive. For some it can be a disadvantage, but I think it gives an enormous flexibility.

This is somehow the JavaScript you-can-do-whatever-you-want philosophy smuggled into TypeScript But in a much smarter way. I’m sure that when you start working with TypeScript you’ll get what I mean by its wisdom

Small effort, huge benefits

Last, but not least, I must admit that migrating to TypeScript was quite an easy and smooth process. The value for the effort is huge. You get a typed world with very little work.

Migrating to TypeScript struggles

During the migration process we met few difficulties. Some of them we managed to solve fully or partially. If you have any better ideas on these things, feel free to let me know in the comments.

Complexity of webpack configuration

When switching to TypeScript we had few issues with webpack configuration. We have used babel-loader before for transpiling JavaScript and initially we wanted to keep it in the TS compilation process. We first tried to keep babel-loader for JS(X) files and use ts-loader for TS(X) files, but it didn’t work – we were getting weird compilation errors.

Then we tried to compile everything using ts-loader and then recompile it again using babel to ensure (as we initially thought would be wise) backwards compatibility. We also couldn’t make it working.

Finally, we decided to compile everything – both JavaScript and TypeScript files – using ts-loader (including React files). It worked, except source code maps. When we tried to debug in Chrome console it seemed the source code is not refreshing properly after rebuilding. Breakpoints were often not hit and the debugging didn’t seem right.

After a bit of struggling we found a solution. We set devtool webpack option to eval-source-map and configured source-map-loader for .js files. Finally, the proper part of webpack config looks as follows:

So far we also haven’t noticed any issues related to backwards compatibility that were theoretically solved by babel. TypeScript compiler does its job very well.

Complicated JS -> TS refactoring

I found out that JS to TS refactoring is not always an easy task. Some things that are allowed by JavaScript are not valid in TypeScript. In most cases it means that something was wrong with your JavaScript code, but we all know how it is with legacy code refactoring

As an example, we had several functions that we added to a String prototype in JavaScript:

Such code becomes invalid in TypeScript:

A non-obvious solution to that issue is to extend String interface by declaring typed functions you want to add:

There are more subtle difficulties like that you can meet while migrating JS code to TypeScript. However, in the end it gives you a possibility to make your codebase better.

Keeping view models in sync

An issue I didn’t think about before migrating to TypeScript was a need to keep frontend and backend view models in sync.

One of the first things you’d like to have in your TypeScript codebase is to have as much typed data as possible. We use .NET and C# as the backend of our application. ASP.NET MVC controllers returned the strongly-typed objects into the previously chaotic and untyped JS world. Now we are strongly-typed with TypeScript, so we’d like all this data typed as well

Here comes the problem. First of all our C# data models which we returned from the controllers were not the best. In most cases we returned a DTO object which contained many properties from which only few were used by JavaScript code. We never saw this problem, because in JS we just dynamically typed properties names we wanted to use. We didn’t see how much of not needed data is sent from ASP controllers to the web browser.

Now with TypeScript we needed to create these objects definitions also in TypeScript. Having a huge DTO object returned from the controller, with another X objects on which this DTO depends, it was a nightmare. It turned out that for a single DTO I had to create 10-15 TypeScript objects just to use 5-10 properties in the frontend code!

That’s the moment when we came to the necessity of creating web view models. The idea is to return a view model from a controller, not the whole DTO object. This view model contains only the data which is needed by TypeScript (frontend).

I think this is nothing new for experienced web developers. However, now comes the question: how do we keep backend (C#) view models in sync with frontend (TypeScript) ones?

Unfortunately, I haven’t found a perfect solution for that. The best method I came up with is… manually keeping these view models in sync.

There’s a C# to TypeScript VS Code extension which allows to paste the copied C# code as its TypeScript equivalent. It makes the job a bit easier. It even has a CLI tool, but it produces a single .ts file from a single .cs file. If you have multiple objects in a single C# file it will produce a single TypeScript file with all these objects. If any of those objects is used in other files (unfortunately we have many of such cases), these dependencies will not be automatically added as imports in the auto-generated .ts files.

However, I don’t find it very problematic for now. As soon as the TS view models are created, we just need to update them as often as we update C# view models. I think this is a very common issue so if you know any better solution here – please share in the comments

Migrating to TypeScript – summary

Migrating to TypeScript has been a very interesting and rewarding process. Compared to vanilla JavaScript, TypeScript lets programmers see many problems. This allows to see how bad our codebase was. We even realized that our server-side C# code was not the best (see the section about view models above). Thanks to introducing TypeScript we improved a lot of our JavaScript and C# code, including its architecture.

I think that TypeScript uses many simple concepts under the hood and it makes a lot of things possible (see keyof or unknown). In many cases TypeScript lets you do something, but doesn’t force you to do it. That’s the beauty of this typed JavaScript world

The post Is It Worth Migrating to TypeScript? appeared first on CodeJourney.net.

What is a widget?

If you ever worked with a web framework like React, you should know the concept of components. Flutter widgets are directly inspired by this idea. Widget is a reusable piece of code, which describes how your application’s UI looks like. Widgets define the user interface by their state. In some cases, the state can be static and not change over time – see the section below about Flutter widget types for details.

As soon as a widget’s state changes, Flutter rebuilds its outlook and in effect re-renders the GUI. The framework is said to do it efficiently by measuring what has changed in the widgets tree since the last rendering and re-paints only what’s necessary.

The most basic Flutter app might look as follows:

The runApp() method takes a Widget as its argument. In our case, it takes a Center widget, which has one child – a Text widget. As expected, such a simple Flutter app shows a “Hello Flutter!” text at the center of the screen.

This simple example shows us a few interesting facts:

• there are many built-in widgets, like Center and Text
• widgets can have a child or children – this is widgets nesting and it happens all the time and can be very deep
• Flutter widgets can have their own properties, like textDirection.

Widgets nesting sometimes makes simple Flutter apps having a lot of source code inside a single file. However, as I mentioned in the previous post, don’t get discouraged by that Actually, having a lot of nested widgets in Flutter is a good practice. If you have a few huge widgets without much nesting instead, it means that there’s something wrong with your implementation. Flutter widgets – as all reusable pieces of code – should not have too many responsibilities. SOLID also applies here

Viewing Flutter widgets with Flutter Inspector

As widgets tree may get big and quite heavily nested, there’s a very useful tool to easily view and explore it. This tool is called Flutter Inspector.

While in debug mode in Visual Studio Code, you can launch it by clicking the blue magnifier icon:

It opens in a web browser and allows you to see the whole widgets tree in your app:

There’s a very handy feature “Select Widget Mode” which, when enabled, lets you select the widgets directly in your emulator or phone. After doing this, you can see the selected widget’s properties in the inspector.

Types of Flutter widgets

In Flutter, you can – and will – create your own widgets. Widget is just a Dart class which extends a proper base class. Depending on whether your widget actually manages any state and changes over time, you have two types of base classes to inherit from – StatelessWidget or StatefulWidget.

The main purpose of each type of widget is to provide an implementation of a build() method which returns a Widget object. However, each widget type does it a bit differently. Let’s see this in action.

StatelessWidgets

The simplest widget you can create is a stateless widget. You create it by simply creating a class extending StatelessWidget. Here’s the sample source code and a view it generates:

	import 'package:flutter/material.dart';
	void main() => runApp(
	MaterialApp(
	title: "My CodeJourney Flutter app",
	home: Scaffold(
	appBar: AppBar(
	title: Text("My First App"),
	),
	body: MyFirstWidget(),
	),
	),
	);
	class MyFirstWidget extends StatelessWidget {
	@override
	Widget build(BuildContext context) {
	return Container(
	padding: EdgeInsets.all(8.0),
	child: Text(
	"Hello MyFirstWidget!",
	style: TextStyle(color: Colors.green),
	),
	);
	}
	}

view raw main_stateless_widget.dart hosted with ❤ by GitHub

You can play with it yourself in the DartPad.

There are quite a few new things in the source code. Let’s point them out:

• as our main widget, we used MaterialApp and provided it to runApp() method. MaterialApp widget gives us material design for our app out of the box. As soon as you use it, you can nest more material widgets from the widgets library. There’s a similar widget for Apple-oriented widgets called CupertinoApp, which allows using Cupertino widgets
• we used another material widget – a Scaffold. It provides us with an appBar and body properties – setting them we’re getting this nice-looking application’s skeleton with entitled app bar and home for our widget. Scaffold also gives us many things “for free”, e.g. FloatingActionButton
• body of our Scaffold is our first own stateless widget – MyFirstWidget. As mentioned before, it overrides the build() method, which simply returns another widget tree. Notice the usage of a Container widget, which is very useful for grouping other widgets.

StatelessWidget is simple, works and is just there Let’s see something more interesting now – StatefulWidgets.

StatefulWidgets

When you want your widget to change over time and maintain its state (in most cases you do), you can create a stateful widget. You do it by creating a Dart class extending StatefulWidget. Unlike StatelessWidgets, StatefulWidget doesn’t override the build() method. Instead, it implements a createState() method, which creates the initial widget’s state (see below).

Apart from the main widget class, which itself is still “final” (or better said – immutable), you create a class extending State. This class maintains the actual state and it is now who provides the build() method’s implementation.

Let’s see the sample code and produced GUI:

	class MySecondWidget extends StatefulWidget {
	MySecondWidget({Key key}) : super(key: key);
	@override
	_MySecondWidgetState createState() =>
	_MySecondWidgetState();
	}
	class _MySecondWidgetState extends State<MySecondWidget> {
	int _clickCount = 0;
	void incrementClickCount() {
	setState(() {
	this._clickCount++;
	});
	}
	@override
	Widget build(BuildContext context) {
	return Scaffold(
	appBar: AppBar(
	title: Text("My First App"),
	),
	body: Container(
	padding: EdgeInsets.all(8.0),
	child: Text(
	"Hello! Times clicked: "
	+ this._clickCount.toString(),
	style: TextStyle(
	color: Colors.green,
	fontSize: 20.0),
	),
	),
	floatingActionButton: FloatingActionButton(
	child: Icon(Icons.add),
	onPressed: this.incrementClickCount,
	),
	);
	}
	}

view raw main_stateful_widget.dart hosted with ❤ by GitHub

The full code you can play with is available in the DartPad.

Now some comments about the StatefulWidget code:

• notice how MySecondWidget class passes a key to its superclass. Concept of Flutter widgets keys is interesting and we’ll dig into it in a separate post. For now, just treat it as a convention to always accept a key as a named argument and pass it to the base class
• as said before, in this simple example, MySecondWidget only creates the initial state by instantiating _MySecondWidgetState
• you’re already familiar with most of the code in _MySecondWidgetState, but notice the usage of setState() in incrementClickCount() function. It tells Flutter that the state has changed, so the framework can re-render the UI. If you directly change the value of this._clickCount without calling setState(), GUI will not be updated until setState() is called in some other place. We’ll talk more about state management techniques in Flutter in the future articles
• note how easy it is to add a FloatingActionButton thanks to using Scaffold material widget.

That was easy and works nicely! You now know how to use both Flutter widget types

Flutter quick actions in VS Code

I’d like to share with you two easy tips for working with Flutter in Visual Studio Code. Both speed up the development nicely. It assumes that you configured VS Code properly (if not read this article) and have Flutter extension installed.

Ctrl + .

First important keyboard shortcut is Ctrl+. (Cmd+. on Mac). It allows you to perform many element-contextual actions. For me it’s most useful for removing widgets or wrapping widgets with other ones:

Snippets for widgets creation

Another useful feature are code snippets for creating widgets. You use them by starting to type their acronym in your .dart file. There are two acronyms for widgets creation – stless for StatelessWidget and stful for StatefulWidget scaffolding. The usage looks as follows:

Most popular Flutter widgets

I wanted to list you here some most popular Flutter widgets, but they are quite well described here. You can also search through the widgets library. We’ve also used quite few of them in our examples above

Community widgets

Many more people are starting to use Flutter and they also create a lot of community widgets. You can find the Dart packages for Flutter on pub.dev. I also recommend checking the Flutter Awesome website where the best Flutter widgets, libraries and other extensions are listed.

Summary

That’s it! You’ve just learned how to use stateless and stateful widgets in Flutter. We’ve also seen what’s the difference between them and what are some basic conventions in creating them. There’s a lot more to Flutter widgets and related topics, but these are topics for separate posts. I hope to publish more of them soon

In my opinion, bringing components into the mobile world in the form of widgets is a very nice idea. They give quite a good separation of logic and GUI management. For sure it’s a fresh start, totally changing the way in which we think about mobile apps development. Components have done their job in the web world, so why would widgets not succeed in mobile apps? We’ll see!

What do you think? If you are interested in some particular topics related to Flutter – let me know!

The post Basics of Flutter Widgets appeared first on CodeJourney.net.