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.

What is Flutter?

Flutter is an open-source platform and development kit created by Google. You can use it to create mobile (Android, iOS), desktop (Windows, Mac, Linux) and recently also web applications.

Flutter is quite new, as it’s first official version 1.0 was released in December 2018. Before, it was developed and used internally by Google for a few years.

Since this time, countless Flutter apps have been published. You can find their list for instance here. One of the most well-known Flutter apps is Xianyu app created by Alibaba and used by 50M+ people.

The main purposes of Flutter are claimed to be fast development, beautiful and consistent UIs and native performance on each platform.

Dart as a programming language

Flutter uses Dart as a programming language. Why is that? Well, of course, Dart is also developed by Google However, one of the real reasons is believed to be performance.

As you probably know, Flutter is not the first (and not the last) cross-platform mobile development platform. Its main competitor is React Native, which uses JavaScript. Dart compiles to the given platform’s native machine code. Thanks to that, it doesn’t have to use a JavaScript bridge to interact with native components that React Native apps have to do. I don’t know how true this is in real life and how it helps with performance, but that is one of the reasons for using Dart as a programming language for Flutter apps.

Dart is a UI-oriented language. For C/C#/Java developers, Dart’s syntax will be rather familiar and easy to learn. It’s object-oriented, including support for classes and interfaces. The language is type-safe, meaning it combines static and runtime types checking.

Dart is supported by its virtual machine, which also provides – amongst others – a garbage collector (if you don’t know what the GC is, check out this post).

Here’s a simple program written in Dart:

You can play with the code yourself in the DartPad.

Another interesting feature that is possible thanks to Dart is the hot reload. We’ll explore it later, but it significantly speeds up the development and testing time.

If you want to learn more about Dart, check out the official docs.

Everything as a widget

The main concept in building Flutter apps are widgets. In Flutter, everything is a widget – buttons, texts, menus, colors, themes, spacings and paddings. Even your Flutter app is a widget.

What’s very interesting is that Flutter doesn’t use platform native widgets. Instead, it provides its own set of widgets for each platform, e.g. Material Design for Android and Cupertino widgets for iOS. Additionally, as a programmer, you can create your own widgets. Thanks to that, all Flutter apps look pretty much the same on every Android/iOS version. You don’t need to worry about some UI elements changes between OS releases. At the same time, an app built using these widgets looks like native GUI.

Thanks to the widgets concept, Flutter apps can be easily personalized and branded. Recent researches show that customers are now starting to prefer more specific-looking apps to standard and boring native-designed UIs.

The drawback which I see about widgets is that there’s normally A LOT of source code in Flutter apps. Don’t get confused straightaway

Installation and configuration

Now, let’s get into the real work. It surprised me how easy it is to start working with Flutter. As you’ll see in a moment, you can build quite a nice-looking mobile app with Flutter in less than 30 minutes!

There are several possibilities to work with Flutter. You can easily set up Android Studio or IntelliJ. For example purposes, we’ll focus on running and debugging an Android application on Windows PC using Visual Studio Code. If you’re on Mac or Linux, check out a corresponding official installation guide.

Install Flutter and Android SDK

The installation process is quite easy. Initially I wanted to describe it here for you, but actually the official installation docs do it pretty well I’ll just guide you through the steps below with links to the official installation guide.

Install Flutter SDK and Android Studio

First of all, install Flutter SDK and Android Studio (which is required for Android SDK) following this installation guide. The process is fairly easy and should not take more than 15 minutes. Remember about using flutter doctor command to verify if everything is installed correctly – it gives very clear messages. In the end, using VS Code and having Android phone connected in USB Debugging mode, your flutter doctor command should have an output similar to mine:

Configure Visual Studio Code

The next step is to configure Visual Studio Code to be able to develop, compile, run and debug Flutter apps. You only need to install the Flutter extension, which is very well described here. It should also automatically install the Dart VS Code extension which adds Dart language support to VS Code.

Your first Flutter app

Now let’s finally create this first Flutter Android application It’s probably gonna be the quickest part!

Create and run a sample app

First of all, open Visual Studio Code. Use Ctrl+Shift+P to open a Command Palette. Start typing “Flutter” and select Flutter: New Project:

In two next steps specify your project’s name (e.g. “hello_flutter”) and choose a location where the template should be generated.

Wait until VS Code generates the whole project and you see main.dart file in lib folder:

Open the main.dart file and replace its contents with the following, a bit cleaned-up code:

We won’t focus on the source code here – I hope to dig more in the coming posts Just notice there are quite a few widgets – can you count them all? I found at least 12 different widgets used in this small template code.

Now the best part – having your Android phone connected (you should see it in the right-bottom corner of VS Code) press F5 to run the application. After a few seconds (usually longer for the first time) you should see this beautiful application on your smartphone’s screen:

As soon as you press the “+” button the green counter increments. Yaaaaay!

Debug your Flutter app

Now, try putting a breakpoint in main.dart file at line 30 (beginning of _incrementCounter() function). When you click the “+” button next time, VS Code should stop at the breakpoint:

Try hot reload

The best for the end. As I mentioned before, Flutter lets you use a hot reload. It lets you change the code while running the app and see the changes immediately after saving the source code file. I love it especially because it’s a stateful hot reload, meaning that except UI the state is also reloaded (or rather kept).

With your Flutter app running in debug mode, click the “+” button several times so the counter has value > 0. Then go directly into VS Code and modify line 50 by changing the counter text color from Colors.green to Colors.red. Line 50 should now look as follows:

Save main.dart file by pressing Ctrl+S. Take a look at your smartphone and see the magic:

Notice how the color of number “7” (counter value) changed to red while its value remains untouched. Quite a nice feature for quick development

I noticed that sometimes it doesn’t work that smoothly and you need to restart the app to see the changes. However, it happens only with some bigger code changes. Flutter quite young SDK and tools are still developing quickly so I hope such drawbacks will be eliminated soon.

Summary

Today we’ve seen how easy it is to start working with Flutter. We got familiar with basic Flutter concepts like widgets. We’ve also created our first Flutter app and debugged it. Finally, we’ve seen the very cool hot reload feature in action

For me, Flutter looks promising. After my adventures with Xamarin, which mostly felt like changing Java to C# and Android Studio to Visual Studio, I’m excited to try something fresh and totally different.

I know this was just a simple introduction to Flutter, but there’s more coming! I hope to publish the next articles about Flutter as I continue playing with it. If you’ve ever used Flutter and have some good sources to recommend – let me know in the comments!

Stay tuned!

The post Your First Flutter App in 30 Minutes appeared first on CodeJourney.net.

Today I’m trying to address the issue of approaching an unknown codebase. I’ll give you some advices and tricks I’m using to make new code easier and quicker to understand – even without understanding it all

Understand the architecture

For me, the first thing to do in a new project is to understand the software architecture. My goal here is to as quickly as possible find answers to the following questions:

• what is a client? Is it a desktop, mobile app or both? Maybe there’s only a web app, but used on different devices?
• what is a server? Is it a single instance or some distributed service? Where does it run?
• how do the client and the server communicate? Is there any framework used (e.g. WCF) or maybe just some RESTful web service communication?
• are there any architectural design patterns used by the team in both clients and server apps (e.g. Layered Pattern, MVC, MVVM, CQRS…)?
• what are the important frameworks/libraries used in the clients and server apps? By important I mean these ones which directly define the style of coding, for instance: ASP.NET MVC, WPF, Caliburn.Micro, Prism, Spring, Angular, React, TypeScript etc.

Answering these few questions will give you a feeling of where is what When working with some tasks you’ll automagically feel where the issue may be or where to look for a solution (or problem ).

It’s sometimes helpful to draw the architecture on a paper or whiteboard to help you easier grasp the elements and connections between them.

Learn the persistence

Each application stores its data somewhere and you should know where and how it does it. At least it’s a bit helpful

First of all, find out what kind of database is used by the software. Then check how the applications (clients, server) communicate with the database. In other words: find out in which place the queries are sent to the database. I really mean it – if SQL db is used, find out where exactly the SQL statements are generated and sent to the server. Maybe there’s some ORM (like Hibernate/NHibernate or Entity Framework) used for that?

Next, find out how is the persistent data (e.g. tables) represented in code. Where are the persistent classes defined? How are database restrictions (not-null fields, primary and foreign keys, constraints, data types) defined on them? How are the objects’ fields mapped to database tables’ columns?

In the end, try to understand how these persistent objects are presented in the GUI. Are there any DTO objects used? How is a business validation (e.g. maximal length of a field or email validator) defined for these objects (maybe some validation library is used)?

Knowing the persistence layer and its functioning in the software will help you work with your new, yet unknown codebase. You can often be assigned to issues related to database limitations or business validation and knowing where is what can significantly ease your pain

Learn to deploy your system

It may sound obvious, but you should quickly learn by heart how to deploy your system (or part of the system you are working on) from scratch.

Compile the whole code and learn how to run it all (server and all clients). If possible, start with a clean database as a new customer would. If the process is complex write down the step-by-step instructions while your colleague explains the process to you. It’s very important that you practice it yourself and finally are able to go through this “deployment” process even without your notes.

Know the system functionally

Among the first steps for approaching an unknown codebase you should… put the code aside and focus at least a bit on the functional side.

As soon as the whole system is running, spend some time clicking through the application. Try to grasp how it works, what’s the feeling of the system.

If possible, find someone who has functional knowledge about the software – preferably a consultant or customers’ trainer – and ask him/her for a live demo. It would be best if they can give you an introductory demo as they do for end customers. Ask as many questions as come to your mind during such a presentation. If possible, leave some communication channels open with the person who trained you, e.g. a chat where you can leave your potential doubts/questions. Ask him/her to answer them from time to time. Also, check with the presenter if there are any resources on the problem domain of the system.

The better you understand the problem domain, the better your technical decisions are going to be. Sometimes you don’t need to understand everything – even consultants or designers may not always know what clients are really using the system for. However, it’s important to understand as much as possible from a functional point of view. Such a perspective helps you think differently when you’re asked to implement a feature that initially sounds like nonsense. Maybe that’s really what customers need to solve their domain problems?

Explore source code tests

This part becomes more meaningful when you’re assigned your first tasks. I don’t recommend exploring all the tests in your application before you start working – except if these tests are veeeeery good and really human-readable (which I’ve honestly never seen so far ).

As soon as you’re starting to work on some task you may have the feeling that you completely have no idea how the related part of the software works. If that’s the case, try to look for tests (unit, integration tests) in the code related to this feature. If your “issue” is related to a need to make some changes in a particular method, try to find this method’s usages – hopefully, it’s called by some tests:

Exploring the tests can give you an idea of what an author-developer had on his/her mind when writing this code.

Of course, as soon as you make any changes in the code, run all tests to make sure you didn’t break anything Especially the tests related to what you’ve changed. The best obviously is when you have a build server that runs the tests for you.

Have software documentation around

If there’s any documentation for your new software – have it somewhere around. Don’t read it – except, again, if it’s veeeeery good and interesting (anyone has ever seen such docs?! ). Just keep it in case you need to find out how something works. You can always search such documentation by phrases/keywords related to the task you’re working on. Maybe it’ll help you to at least reproduce the problem

Document your actions

When I work with an unknown codebase I tend to keep track of what I’m doing. This is also one of my productivity tricks. I create a new project in Nozbe (tasks/projects management application which I’m using) for each task I start working on. It can also be a new Notepad file, a new tab in Sublime Text or just a piece of paper. In such a place I write down what I’m currently working on. If I have some exception’s stacktrace I’m trying to analyze – I paste it there. I write down some objects and try to picture the relations between them.

Simply writing down stuff in a “natural language” often helps me find a solution quicker. Have you ever started to ask someone for help and as soon as you explained to him/her your issue, you suddenly got an idea of how to solve it? It works similarly with writing things down – it’s like explaining stuff to yourself. Just give it a try

Debug

Obvious, right? Well, not necessarily. I often see people debug only when they know exactly what to debug. When working with an unknown codebase I find it helpful to break through the application’s startup. Put a few breakpoints in one of the application’s entry methods and debug how it launches and initializes line-by-line.

It will help you to see what components are used and how are these loaded.

Do the same with given actions you want to understand. If there’s some button that causes an issue later on (not directly after pressing it), put a breakpoint in a method that is assigned to a button and try to debug step-by-step until the exception is thrown. It will let you understand how the codebase is built and what the developer exactly intended to do with this button.

Search literally

I think most of us do that, but very few confess

When working with an unknown codebase I very often search for things literally. For instance, when working on an issue occurring on pressing a button it may not be easy to find the code-behind the button (a method which executes as soon as you click it). In such a case, I just copy the text which is a button’s text or name and search by it literally in the whole codebase. It can even be one of the translated resources – their values are often stored somewhere (e.g. in XML files). This often allows to quickly identify a method attached to the button just by finding the string or the translation key’s usages

If you don’t have any GUI element with text to search for, try to search by intuition For example if you’re trying to find a code that handles saving a document, just search by strings like “SaveDocument”, “AddDocument”, “UpdateDocument” etc. It can greatly help you find what you need!

If you’re using Visual Studio with ReSharper there’s a really useful “Search everywhere” feature which allows you to easily search strings literally in the whole solution:

Don’t be afraid to ask

Not asking is a common issue, especially amongst experienced developers. Programmers are often afraid of asking questions. New guys in a team tend to think that it would be a shame to ask someone for such easy stuff… But hey, you’re new in the team and it’s perfectly fine to ask for anything that comes to your mind!

I’d say even more – by asking questions you show your engagement and a will to really understand what you’re doing. Sometimes digging into an issue ourselves can be much longer than doing it with a little bit of help from the project’s seniors. So by asking them to aim you in the right direction you’re also saving yours and your company’s time

When working as a team leader I preferred to have people in my team who asked questions to silent on-my-own geeks. Of course, you should first try to find the solution yourself, e.g. using one of the tips described above However it’s always better to ask and get the answer or be aimed in the right direction in 5 minutes than spending the whole day fighting with the problem. It would also make your day much better

Summary

I hope these few tips will be useful for you

Don’t be afraid of an unknown codebase. Don’t try to know it all straight away – you don’t need to and even shouldn’t If the codebase is huge, you’ll potentially never know it all. Just grasp the main concepts and architecture. Be in touch with your teammates and don’t be ashamed of asking them questions – with time, you’ll ask less

I think that one of the factors showing a developer’s experience or seniority is the ability to work with code he/she doesn’t know. Very often to fix a bug you need to change a single line of code. The trick is to find that line

I’m very curious what are your techniques for approaching an unknown codebase? Do you have some tricks to quickly find yourself in legacy code you don’t know? Share your tips with us in the comments!

The post How to Start Working with an Unknown Codebase? appeared first on CodeJourney.net.

How will this possibility change the way we write C#? Why is it being introduced? I’ll try to address these questions today

Interfaces today

As we all know from the current version of C#, interfaces allow to define a kind of contract, which must be respected by a class implementing it. Today interfaces can only contain definitions of methods (with no body). These methods are then actually implemented by concrete classes. If a class doesn’t implement all of its interface’s methods, compiler produces an error.

What’s problematic in this approach? Assuming that you have the following interface and class(es) implementing it:

With time, you may want to extend IDeveloper interface by adding a new method, for instance:

Now you have a problem, because the new method must be implemented in all places where the interface was used. Compiler gives you an error as long as it’s not done:

If your interface is used in many places, also by another teams or developers (which is often the case in reality), this is a breaking change

It may be really painful, depending on how extensively your interface is used. In any case, all classes based on the IDeveloper interface must implement the new LearnNewLanguage(string language) method. Only then the code compiles.

One of the reasons for introducing into C# default interface methods is to avoid such breaking changes scenarios

Default Interface Methods

As we can read in the feature’s design notes, an inspiration for it is a similar concept already alive in Java – Default Methods.

The main idea of this new C# feature is a possibility to provide a default implementation of an interface’s method.

Realization in C# 8.0

In our example using C# 8.0 we’ll be able to implement it as follows:

In that case, our class implementing the IDeveloper interface can legally not implement this new method and there will be no compilation error:

Notice that it only works when BackendDev is contextually treated as IDeveloper. It means that a class doesn’t inherit members from the interfaces it implements:

What about multiple inheritance?

As some of you probably realized, this new feature exposes C# to a multiple inheritance problem (also known as Diamond of Death). So far C# didn’t have this issue, because we can only inherit from a single class. We can implement multiple interfaces, but so far the interfaces couldn’t provide methods’ implementation. Because of that, there was no Diamond of Death possible. Soon it’s gonna change

Diamond of Death in C# 8

In case of C# default interface methods we may illustrate this issue with the following code:

Please note that the syntax or places in which compiler generates errors may still change in the final feature’s version.

To better illustrate this Diamond of Death example, take a look at the following diagram:

The question is: which method should be called in such case?

Solution: most specific override rule

C# 8.0 will solve this issue by introducing the most specific override rule. It means that in our case illustrated above, the compiler will issue an error and won’t let us do this.

To avoid this ambiguity, we’ll be forced to implement or override LearnNewLanguage(string language) in IFullStackDev interface. Only then it will be considered the most specific version of the method in the interfaces hierarchy we have. It will then be used when calling the method on objects contextually treated as instances of IFullStackDev. We could also implement it directly in the Dev class and use the class (not interface) type. It would then call the most specific method from the class. This way multiple inheritance issue will be eliminated.

Compiler for the rescue

There are a lot of other potential ambiguity scenarios that may take place after introducing into C# default interface methods. You can check all of them with potential solutions well-discussed on GitHub.

The general assumption is that all code which may lead to issues related to default interface methods implementations is detected by the compiler. In effect, we should get appropriate errors when compiling the source code. That way, programmer can fix all potential conflicts directly when these arise.

What about .NET Framework?

What’s interesting with default interface methods is that it requres changes in the runtime. According to current assumptions, it means that this feature will not work with .NET Framework! Only CoreCLR and Mono stack runtimes are going to receive these new updates.

Summary

As the motivation for introducing into C# default interface methods the language team members mention possibility to interact with some Android and iOS APIs, which already support such feature. They also claim that C# will get the traits programming language feature with default interface methods.

In my opinion this is the most controversial from all C# 8.0 new features. It completely changes something which was obviousness for the developers for years. Probably we’ll see less breaking changes issues when the interfaces are extended, but looking on the list of issues and edge cases it produces… Maybe assuming it already works in a similar way in Java we should just accept it?

Another interesting, .NET-specific aspect is that this feature will not work with .NET Framework. It’s probably the very first moment when the difference in pace between .NET Core and Framework is so explicit.

I’m also very curious about the performance implications of default interface methods. I’ll for sure be following this issue on GitHub to see how it evolves

What do you think? Is it a good idea to introduce default interface methods into C#?

The post C# 8: Default Interface Methods Implementation appeared first on CodeJourney.net.

Let’s see how this tiny feature is supposed to make our life easier

Goal of slicing

The main purpose of introducing slicing into the language is to make working with arrays and strings easier.

Currently, when you want to retrieve a fragment of an array (X elements from the array, located for instance in its middle), you can use LINQ, i.e. combination of Take and Skip methods. You can also create some extension method to provide kind of slicing.

To illustrate the current way, using LINQ to retrieve only 2nd, 3rd and 4th elements of an array looks as follows:

C# community and designers decided it’s not convenient enough, so are now adding to C# 8 indexes and ranges (in order to provide slicing)

Index

C# 8.0 comes along with a new object – System.Index. It’s a structure internally and looks as follows:

What’s interesting here, is that the constructor takes the value of the index and boolean flag fromEnd. Let’s see how we can use it in practice:

While the first printed value is nothing special, as you can see we can now use the hat operator (^) in order to index from the end. The following also works:

It means that the ^ operator is a syntactic sugar for Index. I allowed myself to check the IL produced:

As we suspected – an instance of Index is created, passing 3 as value and true as fromEnd (see the constructor parameters above).

Range

Another concept which uses Indexes is a new structural data type – System.Range:

As you can see, it really uses Indexes. We can even try creating it on our own:

This doesn’t really make extracting data from the arrays better than Skip-Take LINQ, does it?

Fortunately, there’s another friendly C# language element introduced called range expression. It can be written as x..y and used directly for indexing:

This looks much better! Let’s see how C# compiler translated our 2 lines of code by looking at the pseudo-C# IL produced:

Even though we could achieve the same with much less LINQ, C# compiler does a lot of stuff for us, keeping our code simpler to grasp.

Ranges in strings

All these operations apply also to strings:

Ranges in foreach loop

Next interesting usage is in the foreach loop:

Summary

I see these “little” C# 8 indexes and ranges as another helpful feature. It’s less breaking and controversial than nullable reference types, still making us write less C# code in the future.

If you’d like to dig the feature even more, I encourage you to read the discussions about it on GitHub, which I always find very interesting

Developers, what do you think about C# 8 indexes and ranges?

The post C# 8: Slicing with Indexes and Ranges appeared first on CodeJourney.net.

Learn about building C# 8.0

C# 8.0 is going to be the next major release of C# language. It should be released by the same time as .NET Core 3.0.

What I find very interesting is C# language GitHub repository. Among others, you can find there very interesting notes from C# language design meetings If you filter well, you can also list so called “proposals”, which are current candidates for new C#’s version (or sub-versions) features. By clicking here you can list C# 8.0 candidates.

I will publish a separate post regarding each feature which I find particularly interesting

Nullable reference types

First of the C# 8.0 features I’d like to discuss are nullable reference types. It seems it’s going to change the way we write our code, so it’s worth knowing this feature.

A bit of history – NullReferenceException

Consider the following code:

Guess what happens after executing this as a console app? Of course, our favorite NullReferenceException is thrown:

In this case, jsDev.LastName is of course set to null.

NullReferenceException has been a nightmare for thousands of developers (and users) for many years. What if, in the cases like our example, we knew before that in this place our object might be null?

New world – #nullable enable

For that purpose, C# development team is introducing nullable reference types. In essence, it makes reference types (like string) non-nullable! However to not be a tough nut to crack, all issues related to assigning null value to non-nullable reference types are presented as warnings, not errors.

In order to use this feature, you need to enable it. You can do it with a preprocessor directive #nullable enabled. We can do it directly in the source code file. In the future, it should also be possible to enable it on project level.

Notice what happens when we enable it in our example:

We’re still able to compile, but this nice warning is displayed As soon as we initialize LastName property in the constructor, the warning disappears:

If you try to cheat, it still works like a charm :

But hey… what if you actually want null in this particular string? You need to explicitly mark your reference type variable as nullable. You probably recall nullable value types like int?, don’t you (read this post if you don’t remember the difference between value and reference types)? Now you can do the same with non-nullable reference types:

Nonetheless, in such case, the compiler still takes care of us:

The final fix is quite obvious – we need to check for null first:

At this stage all warnings finally disappear. You can find the finished source code here.

Nullable reference types in IL

The only thing I found in the IL code compiled from source code with #nullable enabled directive was NullableAttribute applied to properties:

It seems that nullable reference types are implemented by applying this attribute to variables, which is only used by the compiler (runtime is not affected).

Summary

I’m really excited about nullable reference types in C# 8. I personally feel that it even introduces some clarity in the language – we’ll have explicit declarations for nullable value and reference types. However, in more complex scenarios it may bring some confusion in regards to reference types and using “?” character (like generics or collections – see Jon Skeet’s post for more details). For sure it’s a significant step towards eliminating issues with exceptions caused by null references.

What do you think about nullable reference types? Is it a good direction in which C# language is going? Share your thoughts in the comments!

The post C# 8: Nullable Reference Types appeared first on CodeJourney.net.

These features of JavaScript language are the most striking differences compared to C# ecosystem. If you’re about to learn JavaScript, sooner or later you’ll also have to deal with them.

Before we begin, one disclaimer: the goal of this post isn’t stating which language is better or worse. JavaScript and C# are different programming languages and their use cases are also completely different. One is better for some usages, while the other is better for others. The list is my and other readers’ subjective one and you don’t need to agree with all points. I’m myself a C# developer on my JavaScript learning journey, so I’d like to help you grasping these confusing concepts

1. Dynamic Typing

Obviously, the first difference JavaScript newbie notices is that the language is dynamically-typed. It means that the types (of variables, functions, actually of almost everything) are checked at runtime, not at compile time like in C# or Java.

Because of that, there’s not much difference in defining variables and assigning them data of various data types:

JavaScript’s variables are not associated with any particular data type. That’s why it’s completely legit to write something like that:

Because JavaScript is dynamically-typed, issues with types are detected at runtime (e.g. error is thrown as soon as you try to use a variable in a context which expects another data type), not during compilation time as it would be in C# or Java.

If you have some experience with statically-typed languages, you may now feel how much confusion and troubles dynamic typing can bring. At least at the beginning.

2. Implicit types coercion

JavaScript has one more interesting feature – types coercion. Even though this term’s name sounds a bit weird , it’s quite simple: types coercion happens when a value of one type is converted to another one.

3. null and undefined

In JavaScript there are two values which represent kind of unassigned variables: undefined and null. What’s the difference between them? The snippet below clarifies:

5. Hoisting

In JavaScript you can legally write such a code:

As you can notice, name variable is used before it’s declared 2 lines below. This is maybe not that weird, as in JS we can even declare variables without the var keyword, but we can do the same with functions:

So here we call the function before declaring it. Why does this work?

This works thanks to hoisting. It’s a compile-time mechanism which “moves” all variables and functions declarations to the top of our JavaScript code. In fact, during the execution of above-listed code, JavaScript engine processes variables and functions declarations before executing any other code.

It however applies only to declarations, not to assignments:

6. Lexical scoping and this keyword

To create a scope (space in which the variables defined in it are accessible) in JS, we need to create a new function. Variable defined in a function is not accessible outside this function:

It means that other blocks like the ones associated with if statement don’t introduce a new scope:

If a variable is defined outside of any function, it’s assigned to a global scope.

However, in JavaScript we also have something called lexical scoping. It basically makes functions declared within another functions having access to the parent function’s scope, as the following example presents:

Forming such “hierarchy” of functions is also referred to as scope chain. You should remember that it refers to the order in which functions are lexically written, not in which they are called:

As you can see above, as soon as we call a(), which then calls b(), within which we define variable x and then call function c(), inside of function c() we don’t have access to x variable (x is not defined). Why does it happen even though function b() in which x variable is declared called function c()? Because function c() is not lexically written as the child function of b(). Parent scope for function c() is always the global scope.

7. this keyword

All these scoping rules examined above somehow lead to another confusing concept with this keyword. As soon as we define a method on some object and try to print the this keyword in this object’s method, the result seems reasonable:

However, if we just define an inner function in our method and try to print this keyword inside it, weird stuff happens:

As you can see, the this keyword in the innerFunc() function doesn’t point to the blogger object anymore. Instead it points to a Window object, which represents the browser’s window (this used in the global scope points to it).

This happens because in a regular function the this keyword points to the global object (Window object in our case). innerFunc() is here considered as a regular function, not as an object’s method. This behavior may be confusing and is often a subject of dispute in JavaScript community.

8. sort() function

You’re a newbie JS developer and you’d like to sort an array of numbers. You found a sort() method on the array, so why not to use it? You write such code:

What do you expect to be logged in the console? Let’s see:

(5) [-5, 15, 20, 40, 7]

Nice! What happens here? 7 is greater than 40? Well, yes It works as expected, because the sort() function sorts array’s elements as strings and alphabetically. Therefore, if our array contains numbers, the final order depends on the Unicode representations values of each number.

Fortunately, there are ways to use sort() function correctly for numbers, but this functionality is still confusing for new JavaScript developers.

9. Prototypes

Every object in JavaScript has a __proto__ property. We can access it directly on our object or by using Object.getPrototypeOf() method. In both cases, having created an empty object and printing its prototype to the console like that:

produces the same output:

On the top of objects hierarchy, there’s Object. Because of that, our x object is an instance of Object. That’s why the prototype of our x object is actually the Object.prototype, which contains some common methods we can use (like toString()).

If we try to access Object.prototype.__proto__, we’ll see that is contains null.

Prototypes in JavaScript are mainly used to provide some connection between two or more objects (like exposing some common methods).

All this “hierarchy” of prototypes is used to search for fields and methods of objects: the JS engine first searches in the object itself and if it cannot find particular property, it looks in this object’s prototype, and then in its prototype until it finds the first matching occurrence. As soon as it reaches null in the Object.prototype.__proto__ it means that the prototypes chain has ended and undefined is returned.

This kind of prototype inheritance is different than class inheritance, so it’s often confusing for developers willing to learn JavaScript. Actually, I could write a separate post on this, so if you’re interested you can read more for instance here.

10. IIFE

IIFE is an acronym for Immediately-Invoked Function Expression. So what is it and how can it be useful?

Going straight into the code, IIFE can be written as follows:

As a result of executing such script in a web browser, we’ll see the following console output:

Hey!

How does it work? We neither declared a function’s name nor called it, right? Actually, we did

There are two unusual parts of IIFE implementation: outer parentheses in which we “wrapped” our function and “empty” parentheses together at its end.

Let’s start by “wrapping parentheses”:

Why do we declare them? Because if you don’t, JavaScript parser will give you an error:

script.js:1 Uncaught SyntaxError: Unexpected token (

In such case it thinks that we’re writing a function declaration and we forgot about providing the function’s name after the function keyword. Wrapping this into parentheses (…..) tells the parser that we’re declaring a function expression, not a declaration. After doing this, there are no errors anymore.

The second important part is the “empty” parentheses () just after the function expression:

As you know, () allows to call the function. That’s exactly what we do here here – our function is immediately executed.

Why would we need such construct as IIFE? Developers say that it doesn’t “pollute” the global scope. In effect, we are not leaving the function somewhere after being executed, so no one else can call it accidentally from another place. What’s more, IIFE is even considered a design pattern.

You should know that such construct exists even only to know what it does seeing it in someone else’s code. If you want to know more about its use cases, I recommend reading this article.

Summary

In this post we’ve gone through some of the most shocking features of JavaScript language for C# developers. Most of them are confusing for programmers coming from statically-typed and class-based languages and can bring a lot of issues in the beginning of their JavaScript journey.

Just remember that these are the JavaScript’s language features, not its issues or bugs. That’s just how it is, but it cannot be said that JavaScript is worse or better than other languages like Java or C#.

The list for sure is not exhaustive, so if you have anything to add or correct don’t hesitate to leave a comment!

For the end, I’ll just leave you with the following meme-but-true (thanks Youenn ):

Stay tuned!

The post 10 Most Shocking JavaScript Features for C# Developers appeared first on CodeJourney.net.

By execution model I mean a process of having a .NET Framework application actually executed on the machine (CPU), starting from having its source code written. It contains all steps and actions necessary to happen in order to transform source code (like C#) into machine (assembly) code and execute it.

.NET languages standardization

As we all know, .NET is just an execution platform. There are, however, a lot of programming languages which allow us to write code which can then be executed by the platform-specific (not language-specific!) CLR. In order to give programming languages’ creators a set of rules which their language and its compiler must meet to be .NET-compliant, Microsoft defined a Common Language Infrastructure (CLI, also referred to as MSIL in the old days ) which is also standardized by ISO and ECMA.

The main goal of it is to define how the source code should be compiled to the Common Intermediate Language (CIL). As we already know, the CIL should have a standardized format, because it’s then JIT-compiled to a platform-specific assembly code. Some of the most common implementations of CLI are .NET Framework, .NET Core and Mono. I recommend you to check Matt Warren’s article on .NET Runtimes history as well

Common Language Infrastructure implies also some other aspects of the programming language and its compiler, including Common Type System, language-agnostic metadata and Common Language Specification. You can read more about it for instance here.

This all allows us to use various programming languages, like C#, VB.NET, F# or JScript .NET to develop .NET applications. Anyone can still implement their own own .NET language – it “just” needs to conform to the standards.

There’s also another term introduced somewhat around .NET Core – .NET Standard. Its purpose is to allow code sharing between various .NET implementations. It actually defines a set of APIs that each .NET platform should implement. More details here.

This whole standardization makes us arriving to the .NET applications execution model, which is how every standards-compliant CLR application is executed.

.NET execution model

Independently of the language of choice, .NET application’s execution model can be described as the following 4-steps process:

1. Writing source code in a programming language of choice, including the usage of its compiler
2. Compiling source code to Common Intermediate Language (CIL)
3. Compiling CIL into native code – details of this step in the previous post
4. Execution of the native code.

These steps are well-resented on the schema below and then described in details in the next sections.

Writing source code in a programming language of choice

As mentioned before, .NET applications can be implemented using any language of choice, which is compliant with CLI. Another important part is a compiler – it defines a general syntax of the language, kinds of data types that can be used by a programmer etc. For instance, current open-source compiler for C# and Visual Basic is Roslyn.

In the end, role of the compiler is to transform the source code to its CIL equivalent.

The simplest possible complete application written in C# can look as follows:

Compiling source code to CIL

After the source code is written, it must be compiled to CIL, which is an intermediate language understood by the CLR. On this level, the whole execution process becomes language-agnostic, which means that as soon as the code is compiled to CIL it is executed by the CLR and programming language’s features (e.g. its compiler) don’t play any more role.

CIL code looks more like assembly code, however containing some specific instructions. It’s still far more readable than native code. Apart from the direct transcript of source code, CIL contains metadata about the DLL/EXE assembly file.

The C# fragment presented in the previous section compiled to CIL by Roslyn looks as follows:

A bit more than the original source code, isn’t it?

Firstly there is a metadata instructions section which contains information about the assembly, execution framework’s version, types used in the code and external references. Next there’s the actual CIL code (equivalent to C# code presented above) listed.

Compiling CIL into native code

We’ve already covered this step in details in the previous post about Just-In-Time compilation, which is just a bit more fancy name of this process Now you can see how and where it fits into .NET application’s execution model.

Normal JIT compilation

By default, JIT compilation is done in the place where “Normal JIT Compiler” is drawn on the schema below:

IL instructions of a particular block of code, in the example diagram of a method Foo(), are JIT-compiled when the block is to be used for the first time. Then, this JIT-compiled code is stored as the JIT-ed equivalent of Foo() method’s code in the memory cache. Such native code is then executed and if the same block of code needs to be called again in the future, it will not be re-JIT-compiled, but instead the native code will be taken from the memory cache and executed again.

There’s a possibility to skip adding the native code into memory cache for future executions and it’s referred to as “Econo JIT Compilation”, however it’s not widely used and probably obsolete since few versions of .NET, so we won’t examine it here.

Pre-JIT compilation

The schema presented above changes a bit as soon as we want to use so called Pre-JIT compilation. We mentioned it already and we know that one of the techniques to allow pre-JIT (or ahead-of-time) compilation is using Native Image Generator (ngen.exe) which allows to transform CIL assemblies into native code files and to store them as a file on the disk (in the Native Image Cache). It allows to natively compile the whole assemblies – it doesn’t allow to compile only single methods as JIT compiler does.

Refer to the new version of the schema presented below to see how the process changes with NGen.

Normal and ahead-of-time CIL compilation modes provide different cons and pros, including:

• NGen delivers faster start-up time, especially in large applications used by many users in the same time, but requires more disk space and memory to store both the CIL and pre-compiled images,
• JIT compilation at runtime can deliver faster code, because it targets the current platform of execution; NGen produces the native images with instructions that can be executed on all possible platforms, meaning it must use the oldest from currently used instructions sets to be backwards-compatible,
• JIT is able to dynamically re-compile the code for a better performance depending on the execution conditions (e.g. by detecting a hot path in the executed code).

Choosing one of the modes depends on your use case.

Execution of the native code

Finally, the code blocks are run by the CLR, which asks CPU to execute compiled instructions sets. If you’re interested in how CPU exactly works and executes the instructions, I recommend you watching this YT video.

Summary

We’ve seen today how the .NET applications are executed step-by-step, starting from source code (like C#) up to being actually executed by the processor.

I also encourage you to read – if you haven’t already – all the previous posts in the .NET Internals series. Just click here to see them all

Let me know if you have any doubts or thoughts, I’m always open to your comments and opinions Especially the constructive ones pointing out some parts I omitted or didn’t describe precisely enough.

I hope it helped you learn something new

The post [.NET Internals 10] Application execution model appeared first on CodeJourney.net.

What makes managed applications portable?

Intermediate Language (IL)

Viewing MSIL

Just-In-Time (JIT) compilation

How Toyota brought us JIT?

Let’s start by some historical background In the early 1960s, Japanese engineers at Toyota had to reorganize their warehouse management, because they had very high storage costs – delivery of the parts from suppliers took a lot of time, because they ordered a lot in advance. Every delivery had to be handled by someone, so they needed a lot of employees. Ordered parts were stored in the warehouses for a long time, required a lot or storage space and maintenance.

JIT compiler

Following Toyota’s success , CLR creators introduced a just-in-time (JIT) compiler into the framework. Its role is to compile intermediate language code into assembly language according to hardware and operating system’s characteristics (depending on the machine on which the code is being JIT-compiled). Unlike unmanaged languages, in which the source code is compiled into machine language prior to program’s execution, IL is (by default) compiled to CPU instructions at runtime. That’s how .NET engineers made the machine code delivered on time to the CPU.

JIT compiler is a part of CLR (similarly to garbage collector). To make things simple, it can be said that JIT compiles a particular method’s source code as soon as this method is called for the first time. Of course, it takes into account the hardware, e.g. the CPU type and its instructions set to produce correct assembly code. Such machine code is then saved in the cache and re-used every time the same method is called again within the same application’s execution. It means that the parts of the code which are not used (called) during the program’s execution may not be JIT-compiled at all.

Just-In-Time compilation is actually a combination of two approaches: ahead-of-time compilation and interpretation, mixing advantages and disadvantages of both. However, compiling IL code into assembly one at runtime allows for several interesting features like dynamic typing (ability to retrieve the actual object’s type at program’s execution). That’s why JIT compilation is often treated as a form of dynamic compilation.

Another advantage of having JIT compilation is that the source code we write is “further from the hardware”, so it can be made more readable and human-friendly, whereas the metal-touching stuff is “hidden” in the IL (kudos to MSIL developers!)

Can we still compile ahead-of-time?

Summary

In one of the next posts we’ll dig into application execution model in .NET Framework, where we’ll see when and how exactly the JIT compilation process fits into the whole C#->CPU journey

so if you have your own opinion on JIT or any other remarks, don’t bother and share it in the comments!

The post [.NET Internals 09] Just-In-Time (JIT) compilation appeared first on CodeJourney.net.

(De)allocating objects on LOH

As we know from the second post, during allocating the memory only objects of size greater than 85,000 bytes are placed on LOH. There are also some exceptions, like arrays of double which are put on LOH (in 32-bit architectures only) as soon as they reach 1000 (or more) elements (not something around 10626 elements as could be expected). This is quite important to know to be aware what kind of objects have impact on heap fragmentation (more details below).

So we know when the objects are allocated on LOH, but when are they deallocated?

LOH is collected in the same time as the generation 2 collection occurs. It can be triggered if memory threshold for either gen 2 or LOH is exceeded. Conditions for garbage collection can be found in this post.

That’s why keeping large LOH may affect the GC’s – and the whole application’s – performance.

Garbage collection on LOH

LOH fragmentation

The reason why Large Object Heap is not compacted (by default) is because it’s used to store big objects (>85,000 bytes). Copying such amounts of data would seriously incur the performance of garbage collection process.

Anyway, memory of objects allocated on the LOH is reclaimed so it may eventually become fragmented:

We’ll see below how, but .NET keeps track of “Free space” memory blocks to know which chunks are available for new allocations on LOH. When allocating it looks for a block large enough to store the whole object.

However, imagine that there are 2 free space blocks next to each other. Both were marked free, but they represented different objects (maybe they were next to each other on the heap because one referenced the other). What do you think GC will do? Will it treat them as two separate free memory blocks, making less chances for the next allocated object to fit into one of them?

Fortunately not. GC has an optimization introduced which makes such adjacent free memory chunks “merged” together:

How does GC do it? Let’s see in more details.

Free memory representation on LOH

Instead of compacting Large Object Heap, garbage collector keeps the address ranges of not used large objects in a Free Space Table:

As you can see on the figure above, as soon as gen 2 collection run, address ranges of two unused objects were just added to the Free Space Table.

Now you can see that “merging” two adjacent free memory chunks is just a simple addition operation (or modification of one number in the table).

Allocating memory on LOH

As soon as a new large (>85,000 bytes or applicable array) object is to be allocated on the managed heap, GC looks for a single “Free Space” block to hold it. However, it’s rather unlikely that the particular object’s size will fit into one of the free memory chunks. In that case, a new object will be allocated on the top of the heap (just after ‘Object D’ on the figure above).

It may happen that the memory obtained from the operating system for LOH is already used (read here for more info about memory). Garbage collector then asks the operating system for more memory segments to be acquired for LOH. If it fails, gen 2 collection is triggered hoping that some memory blocks will be freed and then the allocation will be possible.

Let’s now think about it for a while. We said previously that LOH collection triggers gen 2 collection. So trying to clean-up the Large Object Heap every time an allocation on it is made would be a potential performance killer.

How does GC solve this issue? Well, in fact, after a lot of optimizations introduced to LOH management in .NET 4.5, the GC takes the following actions in order to make a new allocation of a large object:

• firstly, the GC tries to allocate new objects into one of the free space “holes” on the LOH (it’s quite simple to calculate whether any chunk is large enough to store the object knowing ranges of free space blocks from the Free Space Table).
• if the above fails – garbage collector prefers to allocate new large objects at the end of the heap. Even though it may involve asking the OS for more memory segments, it’s been found to be easier and less consuming operation than performing full GC hoping to free some memory chunks on the LOH first.
• only if the above fails (LOH cannot be “extended”) – GC triggers gen 2 collection hoping to free some additional space that could be used for a new allocation.

What’s worth noticing is that this actions order seems to be good for performance, but can sometimes be a reason of memory fragmentation.

Manual LOH compaction

As you should already know from the previous article, LOH can be compacted programmatically, by setting the GCSettings.LargeObjectHeapCompactionMode property. The simplest way to force LOH compaction is as the following snippet presents: