DEV Community: Sam Walpole

My Top 5 JavaScript Tips & Tricks for Writing Cleaner Code

Sam Walpole — Sun, 08 Aug 2021 08:52:06 +0000

1. Destructuring Assignment

Destructuring assignment allows one or more object properties to be assigned to variables in a single expression. The created variable will have the same name as the property.

let myObj = {
  id: 1,
  name: 'My Object'
};

// without destructuring assignment
let id = myObj.id;
let name = myObj.name; 
// id = 1, name = 'My Object'

// with destructuring assignment
let { id, name } = myObj;
// id = 1, name = 'My Object'

This is most useful when you know that you need to use multiple properties from an object, you need to use the same property multiple times, or the property the you wish to use is deeply nested in that object. In all these cases, using destructuring assignment saves you from all the clutter of getting the object properties through chaining and makes your code more concise and easier to read.

For example, I have recently been working a lot with Leaflet, a Javascript framework for building interactive maps. It is highly customisable and allows you to assign your own properties to different markers on the map. However, accessing these properties can get somewhat messy - we can clean this up with destructuring assignment.

// without destructuring assignment
function onEachFeature (feature, layer) {
  if (feature.properties.hasPopup) {
    let popupContent = `<a href="/feature/${feature.properties.id}">${feature.properties.name}</a>`;
    layer.bindPopup(popupContent);
  }
}

// with destructuring assignment
function onEachFeature (feature, layer) {
  let { hasPopup, id, name } = feature.properties;

  if (hasPopup) {
    let popupContent = `<a href="/feature/${id}">${name}</a>`;
    layer.bindPopup(popupContent);
  }
}

We may have added an additional line of code, but I believe this makes it much clearer and easier to read the intention of this function now.

It is also possible to destructure arrays, which allows you to assign one or more elements in that array to variables. However, I do not personally find myself using this syntax often so I wont cover it any further here. If you wish to learn more, please see the MDN reference.

Finally, if you are using a function that has an object as a parameter, it is possible to destructure that object within the parameter list. This saves you the effort of having to explicitly declare the variables yourself, and makes it clear which properties are required by the function.

function logPerson(person) {
  let { name, age } = options;

  console.log(`${name} is ${age} years old`);
}

function logPerson({ name, age }) {
  console.log(`${name} is ${age} years old`);
}

2. Short Circuit Evaluation & Assignment

The JavaScript logical operators, AND (&&) and OR (||) are known as short circuit operators because they only evaluate the expression as far as necessary in order to determine the result of the boolean expression.

For example, AND requires that both sides of the expression evaluate to true. Therefore, if the left-hand side of the expression evaluates to false, it does not bother to check the right-hand side as it would be a waste of time.

Similarly, OR requires that only one side off the expression evaluates to true. Therefore, if the left-hand side evaluates to true, it doesn't bother to check the right-hand side.

This short circuiting can be useful for adding some safety to expressions involving objects. For example, consider the following function:

function logIfAdult(person) {
  if(person.age >= 18) {
    console.log("Person is an adult");
  }
}

The problem with this implementation is that you cannot guarantee that the person object is not null. If you run this function with a null person, you will get the following error: Uncaught TypeError: Cannot read property 'age' of null.

Thanks to short circuit evaluation, we can add some safety like this:

function logIfAdult(person) {
  if(person && person.age >= 18) {
    console.log("Person is an adult");
  }
}

This is because, if person is null it will evaluate to false (this is because null is a "falsey" value, if this concept is new to you, please read this article too), and the whole expression will short circuit. Only if person is not null will the expression move on to check the right-hand side of the expression, at which point we know it is safe to check and we wont get any errors.

We can exploit this short circuiting when assigning variables too. For example, consider the following function:

function logName(person) {
  let name = person && person.name;
  console.log(name);
}

logName({ name: 'Sam' });
// logs 'Sam'

logName(null)
// logs 'null'

What is happening here? Well in the first example, we pass the function a valid person object. Because the person object is not null, the AND operator moves over to the right-hand side of the expression, and assigns the value of person.name to the name variable. In the second example, person is null so the expression short circuits and returns null to the name variable.

We can extend this further to log a default name instead of just null. This time we use the OR operator, so we will only use the default value if the person object is null.

function logName(person) {
  let name = person && person.name || 'Default Name';
  console.log(name);
}

logName({ name: 'Sam' });
// logs 'Sam'

logName(null)
// logs 'Default Name'

3. Optional Chaining & Nullish Coalescing Operator

Short circuit evaluation and assignment is so common that new more concise syntax is being added in to JavaScript to achieve the same aim. These are the optional chaining and nullish coalescing operators. I have decided to include both short circuiting and optional chaining/null coalescing since, at the time of writing, the latter are newer features and may not be fully compatible with older browsers.

The optional chaining operator (?.) allows you to dive into objects without explicitly having to check if the object is not null. If the object is null, then the expression will just return undefined instead of throwing an error. For example, with optional chaining, the logIfAdult function from above can be rewritten as:

function logIfAdult(person) {
  if(person?.age >= 18) {
    console.log("Person is an adult");
  }
}

The nullish coalescing operator (??) is used to return a default value if the value on the left-hand side of the expression is null. In this way, it replaces the functionality of the OR operator in the logName function above:

function logName(person) {
  let name = person?.name ?? 'Default Name';
  console.log(name);
}

4. Named Callback Functions

Anonymous functions can be really useful - they can be declared when and where you want, and are great if you only need the function as a one-off.

let people = [
  {
    id: 1,
    firstName: 'Sam',
    lastName: 'Walpole',
  },
  ...
];

let viewModels = people.map(p => ({
  id: p.id,
  name: `${p.firstName} ${p.lastName}`,
}));
// viewModels = [{ id: 1, name: 'Sam Walpole' }]

However, since the function has no name, you are leaving it up to future developers to work out what the code inside your callback function does - that's ok here, but in a longer, more complex functions it may waste unnecessary time. By declaring the function first as a named function, you instantly make the code more readable and give future developers some clues as to the intent of the function.

let people = [
  {
    id: 1,
    firstName: 'Sam',
    lastName: 'Walpole',
  },
  ...
];

let toViewModel = p => ({
  id: p.id,
  name: `${p.firstName} ${p.lastName}`,
});

let viewModels = people.map(toViewModel);
// viewModels = [{ id: 1, name: 'Sam Walpole' }]

5. Enums/Dictionaries

An enum is a way to store a set of constant values as a type. Most languages have in built support for enums, but in JavaScript we have to construct them ourselves using an object.

const Color = {
  RED: 'RED',
  GREEN: 'GREEN',
  BLUE: 'BLUE',
};

let redCar = {
  make: 'Ferrari',
  model: '812',
  color: Color.RED,
};

let greenCar = {
  make: 'Aston Martin',
  model: 'Vantage',
  color: Color.GREEN, 
};

Enums pair nicely with switch statements for flow control:

function getHexColor(car) {
  switch (car.color) {
    case Color.RED:
      return '#ff0000';
    case Color.GREEN:
      return '#00ff00';
    case Color.BLUE:
      return '#0000ff';
  }
}

However, sometimes this can be a bit verbose. Instead of using a switch statement here, we could use a dictionary. Dictionaries in JavaScript are declared in a very similar way to enums, but conceptually the have a different purpose. Where enums are a set of constant values, dictionaries are a collection of key/value pairs.

function getHexColor(car) {
  let hexColors= {
    [Color.RED]: '#ff0000',
    [Color.GREEN]: '#00ff00',
    [Color.BLUE]: '#0000ff',
  };

  return hexColors[car.color];
}

In the above example, we have got rid of the need for a switch statement, as we have created a dictionary with the enum values as the key, and the hex colors as the values. By removing all the clutter of the switch statement, I believe that this leads to much easier to read code.

Conclusion

In this article I have provided 5 tips that I regularly use in JavaScript to make my code more concise and easy to read. I hope that you have found them helpful and will find the opportunities to use them in your own code.

I post mostly about full stack .NET and Vue web development. To make sure that you don't miss out on any posts, please follow this blog and subscribe to my newsletter. If you found this post helpful, please like it and share it. You can also find me on Twitter.

A Practical Guide to Higher Order Functions in C#

Sam Walpole — Sat, 03 Jul 2021 10:46:26 +0000

If you have been programming for any length of time, you may well have come across higher order functions, but (like me) may not have fully appreciated just how powerful they can be. If you've not heard of them before, never fear, I have an explanation below.

What are higher order functions?

Simply put, a higher order function is a function whose input or output is also a function.

In the following example, the Map function takes a list of a particular data type and a function, and returns a new list with the function applied to each of the elements in the list (basically equivalent to LINQs Select method).

// definition
List<TOut> Map<TIn, TOut>(List<TIn> list, Func<TIn, TOut> mapper)
{
    var newList = new List<TOut>();
    foreach (var item in list)
    {
        var newItem = mapper(item);
        newList.Add(newItem);
    }

    return newList;
}

// usage
var myList = new List<int> { 1, 2, 3, 4, 5 };

int multiplyBy2 (int num) => num * 2;
var multipliedList = Map(myList, multiplyBy2);
// output { 2, 4, 6, 8, 10 };

bool isEven (int num) => num % 2 == 0;
var isEvenList = Map(myList, isEven);
// output { false, true, false, true, false };

Here is an example of a higher order function that returns a function. First you call the Add function with a given integer, which returns a function that adds that first integer to any given other integer.

Func<int, int> Add(int a) => (int b) => a + b;

var add9 = Add(9);

var sum1 = add9(1);
// output 10

var sum2 = add9(2);
// output 11

Hopefully by now you can see why higher order functions are so useful; they allow complex code to be reused in a highly flexible way by letting the client define their own input/output functions. For example, without the use of higher order functions, one would have to define a new Map function for every single type of mapping they needed.

Practical Example - Repository Pattern

The repository pattern is a very common design pattern used as a data access abstraction. It allows you to perform your typical CRUD operations without the client having to interact directly with the data provider. A typical repository interface may look something like this:

public interface IProductRepository
{
    int Create(Product product);
    bool Update(Product product);
    bool Delete(int id);
    Product GetById(int id);
    IEnumerable<Product> GetAll();
    IEnumerable<Product> GetByCategoryId(int categoryId);
    IEnumerable<Product> GetActive();
    // etc...
}

As you can see in this typical example, there are numerous definitions that all return IEnumerable<Product>, and every time you need another specific type of product filter, that requires adding to the interface and writing an entirely new implementation. That's not great for maintainability...

Instead, using higher order functions, we can define a single method that gets IEnumerable<Product> that takes a filter function as an input. That way the client is free to define their own filters and the ProductRepository doesn't need to keep being updated with new implementations.

interface IProductRepository
{
    // create, update, delete omitted

    IEnumerable<Product> Get(Func<Product, bool> filter = null);
}

public class ProductRepository : IProductRepository
{
    private readonly List<Product> _products = new List<Product>(); // data source

    public IEnumerable<Product> Get(Func<Product, bool> filter = null)
    {
        // typically you might use the LINQ Where method here
        // but using the foreach to be clear what is happening

        if (filter is null) return _products;     

        var filteredList = new List<Product>();
        foreach(var product in _products)
        {
            if(filter(product))
            {
                filteredList.Add(product);
            }
        }

        return filteredList;
    }
}

// client code
var allProducts = _productRepository.Get();
var productsByCategoryId = _productRepository.Get(p => p.CategoryId == 1);
var activeProducts = _productRepository.Get(p => p.Active);

Conclusion

In this article I have introduced the concepts of higher order functions and demonstrated how they are extremely useful in creating reusable and flexible code that is easy to maintain and understand. I have also given a practical use case that you may find in a .NET enterprise application - making the repository pattern more reusable.

Looking after your mental health as a developer

Sam Walpole — Sat, 12 Jun 2021 10:52:22 +0000

It's been over a month now since I last wrote an article here for my blog. I've been struggling a lot with low mood, which has meant that I haven't had the motivation or the energy to produce new content. I have been getting help, which I've found really useful, so I thought I'd share some of the things I've learned in the hope that it might help other developers in a similar position.

Stop comparing yourself to others

If you spend any amount of time online in tech communities, such as on Twitter, you're probably used to seeing people who seem to spend all of their time coding, learning, building side projects, running multiple successful businesses etc. It's almost expected that you have an active social media account with 10,000s of followers, write blog posts everyday, create YouTube videos, get invited to speak at conferences.

I know that I have definitely looked at these people and wished I was able to do the same. It's easy to believe that anything less than this is failure. But the truth is that looking at these people and having such high standards of success for yourself, is only going to leave you feeling inadequate and not good enough.

Every person is different and every person's circumstances are different. Therefore the only meaningful measure of success is against yourself. Are you a better developer than you were 6 months ago? Yes, so that sounds like success to me.

It's great to have aspirational goals and if any of the things I've mentioned above are your goals, then go for it! But remember: 1) they've got to be something that you want for yourself, not what you think you should do based on others expectations; 2) life is a marathon, not a sprint. These things take time and it's not always a linear progression. Sometimes there are setbacks, and that is totally fine. Just focus on being a better you than you were yesterday.

Give yourself a break

Another belief that you'll see a lot in the tech community is that, in order to be successful, you've got to grind. I've certainly been guilty of thinking that all of my time must be spent 'productively', and that doing anything other than work/learning/side projects etc is a waste of time.

But the truth is that feeling fulfilled and satisfied with your life is a two sided coin. Yes, having purpose and been productive is one side of it, but the other side is pleasure and happiness. And to have a well balanced, fulfilled life, you need to spend time in both sides.

So, yes spend time becoming a better developer and work on projects, but don't neglect the other things in life that you enjoy. You'll probably even find that you are more productive in the times that you are working, because you'll have a better mood and feel more motivated!

Focus on now

We can spend a lot of our time planning for the future, which again is a great thing. I do believe that good goals and planning are important for giving your life direction and success. But it can become problematic when we spend all of our time in the future and not enough in the present. We can start to worry and become anxious about the future, or just not be present to enjoy moment that we are experiencing right now.

That's why mindfulness and meditation are very popular right now. They help to ground us in the present moment, allow us to enjoy it more, and be more satisfied. If you're sceptical, I'd encourage you to give it a go. These practices have been shown to really help, and are recommended by the NHS:
Mindfullness NHS Website

Conclusion

I hope that these tips will be useful for you and help you to look after your mental health during this time. Remember to focus on yourself, give yourself a break and enjoy the present moment. Learning to look after yourself can be one of the most important tools for sustaining lasting growth and success.

LINQ: Beware of deferred execution

Sam Walpole — Sun, 25 Apr 2021 10:30:00 +0000

If you've spent much time around C# and .NET, it's likely that you will have come across LINQ (Language-Integrated Query), which allows you to use a range of powerful querying capabilities directly in the C# language.

The example below demonstrate a couple of common features of LINQ (note that I am using the extension method syntax rather than LINQ expressions). In the example, we have a list of people and want to obtain a list of names of the adults in that list. We will then iterate over those names twice (this will be useful to demonstrate the differences between immediate and deferred execution).

Using LINQ, we can:

Filter by age using Where
Map from a Person object to the name string using Select
Evaluate the query to a list using ToList

public class Person
{
    public string Name { get; set; }
    public int Age { get; set; }
}

var people = new List<Person>
{
    new Person { Name = "Sam", Age = 27 },
    new Person { Name = "Suzie", Age = 17 },
    new Person { Name = "Harry", Age = 23 },
};

var adultNames = people
    .Where(person => 
    {
        Console.WriteLine("Filtering by age...");
        return person.Age >= 18;
    })
    .Select(person => person.Name)
    .ToList();

foreach(var name in adultNames)
    Console.Writeline(name);

foreach(var name in adultNames)
    Console.Writeline(name);

/* output
Filtering by age
Filltering by age
Filtering by age
Sam
Harry
Sam
Harry
*/

Notice that in the above example, we explicitly convert the query to a list. This immediately executes the query to give a new list containing only the adult names, which we can then iterate over.

So what happens if we leave off the ToList?

var adultNames = people
    .Where(person => 
    {
        Console.WriteLine("Filtering by age...");
        return person.Age >= 18;
    })
    .Select(person => person.Name);

foreach(var name in adultNames)
    Console.Writeline(name);

foreach(var name in adultNames)
    Console.Writeline(name);

/* output
Filtering by age
Sam
Filtering by age
Filtering by age
Harry
Filtering by age
Sam
Filtering by age
Filtering by age
Harry
*/

Now the output looks quite different. Instead of doing all the filtering first, then iterating over the adult names, the filtering for each item is now happening immediately before we evaluate that item. Importantly, the filtering is also happening every time we iterate over the items. This is known as deferred execution, since we wait until we actually need the values to evaluate the query.

Benefits of Deferred Execution

It looks like deferred execution is the default behaviour of LINQ, unless you explicitly tell it to evaluate immediately (using ToList, ToDictionary etc.). So there must be some benefit to doing this, right?

1. Better Performance

In most cases it is expected that deferred execution will result in better performance, since you don't have to execute the query on the whole data set at once. Instead, you perform the query on one item at a time as you are already iterating over it.

2. Query Construction

Since the query does not need to be immediately executed, you can build it up in several steps, perhaps passing through additional conditional logic. This gives you additional power to create more complex queries.

public IEnumerable<Person> GetNames(IEnumerable<Person> people, bool onlyAdults)
{
    var query = people.AsEnumerable();

    if (onlyAdults)
    {
        // only add this filter when onlyAdults is true
        query = query.Where(person => person.Age >= 18);
    }

    query = query.Select(person => person.Name);

    return query.ToList();
}

3. Always revaluated

Since the query is always revaluated on every enumeration, you can add/remove/change elements of you collection after the query has been constructed and the query will know about these changes. In this way, you know that you are always iterating over the most up to date data.

var people = new List<Person>
{
    new Person { Name = "Sam", Age = 27 },
    new Person { Name = "Suzie", Age = 17 },
    new Person { Name = "Harry", Age = 23 },
};

var adultNames = people
    .Where(person => person.Age >= 18)
    .Select(person => person.Name);

foreach(var name in adultNames)
    Console.WriteLine(name);

people.Add(new Person { Name = "Sally", Age = 26 });

foreach(var name in adultNames)
    Console.WriteLine(name);

/* output
Sam
Harry
Sam
Harry
Sally
*/

The pitfalls of deferred execution

Despite so far singing the praises of LINQs deferred execution, this post was inspired by some of the issues I've been experiencing using it. One of it's benefits is also a pitfall if you do not take enough care when writing your code - the query is always revaluated.

Although deferred execution is seen as a performance benefit generally, there can be cases where it can actually dramatically slow down your application if you're not careful. Any time that you know you will need to repeated iterate over the same collection numerous times (for example a nested for/foreach loop), make sure you call to list first. Otherwise, you will be evaluating the whole collection every single time, which will dramatically reduce performance. This is especially true if the source collection is particularly large since, even if your query does a lot of filtering, the query will be applied every time to the whole source collection.

The final pitfall to mention is using Select to run a collection of tasks. I've seen arguments to say that this is something that you shouldn't do at all, but I've seen it enough in codebases to know that it's something that people do do and something you should be aware of. Imagine the below scenario:

var listOfIds = new List<int> { 1, 5, 8, 15 };

var tasks = listOfIds.Select(id => _repository.GetAsync(id));
await Task.WhenAll(tasks);
var results = tasks.Select(task => task.Result).ToList();

In the above example, the GetAsync method is actually executed twice for every ID, once when it is first declared, and a second time when the query is evaluated using ToList. Not only does this have a massive impact on performance by performing expensive operations multiple times, but also, since the task is re-executed, its not guaranteed to be completed when you actually come to evaluate it. As you might imagine, it is also particularly dangerous if the task you are running is actually a create or update operation (yes I have seen this too). To do the get safely, you need to immediately evaluate the query:

var tasks = listOfIds.Select(id => _repository.GetAsync(id)).ToList();

Conclusion

In this article I have introduced deferred execution in the context of .NETs LINQ. I have shown some of its features and why it can be beneficial compared to immediate execution. Finally, I have discussed some common pitfalls to looks out for when using LINQ and deffered execution.

Handling Dependency Injection in Inherited Classes

Sam Walpole — Sun, 11 Apr 2021 07:39:49 +0000

Dependency injection (DI) is a wonderful thing. Simply add your dependency as a parameter to the constructor (most commonly) of your class, register it with you DI container, and away you go - the DI container will manage the rest. Some of the key benefits of DI are: greater testability, greater maintainability, and greater reusability.

// without DI
public class OrderController : Controller
{
    public ActionResult Post(Order order)
    {
        using (var dbContent = new MyDbContext())
        {
            dbContext.Orders.Add(order);
            dbContent.SaveChanges();

            return Ok();
        }
    }

    public ActionResult Get()
    {
        using (var dbContext = new MyDbContext())
        {
            var orders = dbContext.Orders.ToList();

            return new JsonResult(orders);
        }
    }
}

// with DI
public class OrderController : Controller
{
    private readonly MyDbContext _dbContext;

    public OrderController(MyDbContext dbContext)
    {
        _dbContext = dbContext;
    }

    public ActionResult Post(Order order)
    {
        _dbContext.Orders.Add(order);
        _dbContent.SaveChanges();

        return Ok();
    }

    public ActionResult Get()
    {
        var orders = _dbContext.Orders.ToList();

        return new JsonResult(orders);
    }
}

However, I recently came across a use case where DI can be a real pain - dependency injection in inherited classes.

The Problem

I have recently been working a lot with the Mediatr package, using it's request/request handler pattern to issue commands in the system (inspired by Jason Taylor's Clean Architecture solution).

I typically create a RequestHandler base class that contains common dependencies and functionality. Each concrete request handler can then inherit from this base class.

public abstract class RequestHandler<TRequest, TResponse> : IRequestHandler<TRequest, TResponse>
    where TRequest : IRequest<TResponse>
{
    public RequestHandler(IApplicationDbContext dbContext)
    {
        DbContext = dbContext;
    }

    protected IApplicationDbContext DbContext { get; }

    public abstract Task<TResponse> Handle(TRequest request, CancellationToken cancellationToken);
}

public MyRequestHandler : RequestHandler<MyRequest, MyResponse>
{
    public MyRequestHandler(IApplicationDbContext dbContext) : base(dbContext) { }

    public override Task<MyResponse> Handle(MyRequest request, CancellationToken cancellationToken)
    {
        // handler logic
    }
}

The problem comes when I want to add more dependencies to the base class. Now I have to go through to every single concrete request handler and update the constructor to take the new dependency as well. Fortunately, the code will not compile if I miss one, so there is no risk of a runtime error, but it is still incredibly tedious work to have to update every single request handler. Also, you can end up with very large constructors, which obscures the intention of the class.

public abstract class RequestHandler<TRequest, TResponse> : IRequestHandler<TRequest, TResponse>
    where TRequest : IRequest<TResponse>
{
    public RequestHandler(IApplicationDbContext dbContext, ICurrentUser currentUser)
    {
        DbContext = dbContext;
        CurrentUser = currentUser;
    }

    protected IApplicationDbContext DbContext { get; }
    protected ICurrentUser CurrentUser { get; }

    public abstract Task<TResponse> Handle(TRequest request, CancellationToken cancellationToken);
}

public MyRequestHandler : RequestHandler<MyRequest, MyResponse>
{
    public MyRequestHandler(IApplicationDbContext dbContext, ICurrentUser currentUser) : base(dbContext, currentUser) { }

    public override Task<MyResponse> Handle(MyRequest request, CancellationToken cancellationToken)
    {
        // handler logic
    }
}

The Solution - Dependency Aggregates

The solution to this problem is really quite simple. Rather than injecting the dependencies directly, create a new class that contains the dependencies (known as an aggregate) and inject that instead.

public interface IDependencyAggregate 
{
    IApplicationDbContext DbContext { get; }
    ICurrentUser { get; }
}

public class DependencyAggregate : IDependencyAggregate
{
    public DependencyAggregate(IApplicationDbContext dbContext, ICurrentUser currentUser)
    {
        DbContext = dbContext;
        CurrentUser = currentUser;
    }

    public IApplicationDbContext DbContext { get; }
    public ICurrentUser CurrentUser { get; }
}

public abstract class RequestHandler<TRequest, TResponse> : IRequestHandler<TRequest, TResponse>
    where TRequest : IRequest<TResponse>
{
    public RequestHandler(IDependencyAggregate aggregate)
    {
        DbContext = aggregate.DbContext;
        CurrentUser = aggregate.CurrentUser;
    }

    protected IApplicationDbContext DbContext { get; }
    protected ICurrentUser CurrentUser { get; }

    public abstract Task<TResponse> Handle(TRequest request, CancellationToken cancellationToken);
}

public MyRequestHandler : RequestHandler<MyRequest, MyResponse>
{
    public MyRequestHandler(IDependencyAggregate aggregate) : base(aggregate) { }

    public override Task<MyResponse> Handle(MyRequest request, CancellationToken cancellationToken)
    {
        // handler logic
    }
}

Now if I want to add a new dependency, the only places that I need to change the code are in the DependencyAggregate class and the RequestHandler base class (I don't need to make any changes to the inherited classes).

Conclusion

In this post I have described a simple method for managing dependency injection in inherited classes, by creating a dependency aggregate class to inject into the base class. This ensures that new dependencies can easily be introduced with having to make changes to every inherited class.

Best .NET Posts This Week: 14th March 2021

Sam Walpole — Sun, 14 Mar 2021 15:40:11 +0000

Here are some of the best .NET, C# and ASP NET posts from this week.

This Weeks Articles

Pattern Matching In C#

By Munib Butt

In today’s article we will look at pattern matching in C#. This is a way to match certain members in our objects or the objects themselves to certain conditions and values. This is an especially useful technique to make our code more concise and readable. We will look at several different patterns for matching.

Learn to build HTTP APIs with .NET

By Jon Galloway

ASP.NET makes it easy to build HTTP services that reach a broad range of clients, including browsers and mobile devices. Whether you’re new to .NET or an old pro, we’ve got a lot of fresh videos, tutorials, and documentation to help you learn how to build great HTTP APIs.

Crossing the Generics Divide

By Jimmy Bogard

Generics are great, until they aren't, and when they aren't is when you don't know the type at compile-time but at runtime. This isn't necessarily a bad thing, and isn't necessarily a design problem. Remember, void Main is not generic, so at some point, your program needs to cross the generic divide. Sometimes, this is explicit (you instantiate an object of a closed generic type) or implicit (you use a DI container to inject a closed generic type).

A Cure for Primitive Obsession

Sam Walpole — Sat, 13 Mar 2021 11:28:52 +0000

What is Primitive Obsession?

To start with, primitives are the basic data types available in most languages. These include data types such as strings, numbers (int, floats), and booleans.

Primitive obsession is a code smell in which primitive data types are used excessively to represent your data models. The problem with primitives is that are very general. For example, a string could represent a name, an address, or even an ID. Why is this a problem?

They can't contain any model-specific logic or behaviour, meaning that any logic must be stored in the containing class. This means you end up with classes containing lots of unrelated logic, which violates the Single Responsibility Principle (read more here).
They lose their type safety. A string is a string. The compiler doesn't know if your passing it a string representing a name or an address. This means it is easy to accidentally assign a value to the wrong field, the code will run and compile fine, and you may not notice until the data is completely messed up.
- On a side note, an area that I have commonly experienced this in my career is with IDs. It's common to represent IDs as integers and if you are trying to perform some filtering logic on nested objects (each with their own id), it is surprisingly easy to accidentally use the wrong ID. The code compiles fine, and often appears to work to start with, but then weird bugs start cropping up that are really hard to track down.

Curing Primitive Obsession

Below is an example of a Person class that suffers from Primitive Obsession:

public class Person
{
    public Person(string id, string firstName, string lastName, string address, string postcode, string city, string country)
    {
        // initialisation logic
    }

    public string Id { get; set; }

    public string FirstName { get; set; }
    public string LastName { get; set; }

    public string Address { get; set; }
    public string PostCode { get; set; }
    public string City { get; set; }
    public string Country { get; set; }

    public void ChangeAddress(string address, string postcode, string city, string country)
    {
        // change address logic
    }
}

What is wrong here? Well we have a class that consists entirely of string properties. The constructor consists of a long list of string parameters - I can guarantee that at some point the wrong value will be assigned to the wrong parameter slot! We also have a method to change the address, but really this logic shouldn't be the responsibility of the Person class. Finally, the ID is also a string, so could accidentally be used as the ID for other types.

So what can we do?

Well the first thing we can look at is, are there any properties that make sense to be grouped together? A good test for this is to ask, which of these properties are likely to be updated together? In out example, it is clear that the Address, PostCode, City and Country fields should be grouped (if you move house, it is likely that all or most of these properties will be updated together). Let's refactor these properties into their own class then.

public class Address
{
    public Address(string address, string postCode, string city, string country)
    {
        // initialisation logic
    }

    public string Address { get; set; }
    public string PostCode { get; set; }
    public string City { get; set; }
    public string Country { get; set; }
}

public class Person
{
    public Person(string id, string firstName, string lastName, Address address)
    {
        // initialisation logic
    }

    public string Id { get; set; }

    public string FirstName { get; set; }
    public string LastName { get; set; }

    public Address Address { get; set; }
}

Already our Person class is looking much better. All of the logic to do with the address is now encapsulated in the address class, and we've managed to eliminate a lot of string parameters from the constructor.

You may have noticed that, overall, we still have the same number of string properties. This is fine as ultimately it is likely that you will need to store you data in a primitive. The important part of avoiding Primitive Obsession is encapsulating those primitives into well defined objects that actually represent their meaning.

The next thing that we need to deal with is the ID. To bring type safety back to the ID, we can create what is known as a strongly-typed ID. In short, this is just the primitive value wrapped in a container object specific to that entity. For example, an implementation of a PersonId object might look like (adapted from here):

public readonly struct PersonId : IComparable<PersonId>, IEquatable<PersonId>
{
    public string Value { get; }

    public PersonId(string value)
    {
        Value = value;
    }

    public static PersonId New() => new PersonId(Guid.NewGuid().ToString());

    public bool Equals(PersonId other) => this.Value.Equals(other.Value);
    public int CompareTo(PersonId other) => Value.CompareTo(other.Value);

    public override bool Equals(object obj)
    {
        if (ReferenceEquals(null, obj)) return false;
        return obj is PersonId other && Equals(other);
    }

    public override int GetHashCode() => Value.GetHashCode();
    public override string ToString() => Value.ToString();

    public static bool operator ==(PersonId a, PersonId b) => a.CompareTo(b) == 0;
    public static bool operator !=(PersonId a, PersonId b) => !(a == b);
}

public class Person
{
    public Person(PersonId id, string firstName, string lastName, Address address)
    {
        // initialisation logic
    }

    public PersonId Id { get; set; }

    public string FirstName { get; set; }
    public string LastName { get; set; }

    public Address Address { get; set; }
}

This is good as now the Person class uses it's own PersonId for the ID. There is no way it could be used accidentally as the ID for another type, as that will have it's own strongly typed ID.

However, you may have noticed that this PersonId definition is somewhat large, and it would be cumbersome to have to declare this for every strongly typed ID that you wish to create. To be honest, this hurdle is likely the reason that strongly typed IDs still aren't that common in C# development.

Fortunately, in C# 9, we have the new record type that makes defining strongly typed IDs much easier, so hopefully it's usage will become far more common (you can read more about records here).

// PersonId as a record
public record PersonId(string Value);

// how to initialise
var personId = new PersonId("my-id");

Yes, that's literally it. This declares a PersonId record with a string property called Value, which can be passed via the constructor. Records automatically base equality on the values of their properties, so there is no need to add anything else in the declaration.

Primitive Obsession in F#

Although, this article has focussed mainly on C#, and all the principles applied above can be used in F#, there is a unique feature in F# that I think is worth noting.

Discriminated Unions are a data type in F# (and many other languages, but not C#) that allow different types of data to be returned depending on the situation (to learn more about discriminated unions, please see here). A common use case is error handling:

type Result<'a> =
    | Data of 'a
    | Error of string

This above example, would allow a function to return some generic data type, but if there is an error, return a string.

However, a single-case discriminated union can act as a wrapper for a primitive type, and gives type safety to your functions. For example, we may have this Person record:

type Person = {
    FirstName: string;
    LastName: string;
    EmailAddress: string;
}

The problem here is that an email address isn't really just a string - they have a specific format and so we might want to design some specific validation logic for it. Because of this, it is best to encapsulate it in its own type. With single case discriminated unions this is really easy:

type EmailAddress = EmailAddress of string

type Person = {
    FirstName: string;
    LastName: string;
    EmailAddres: EmailAddress;
}

Now the Person record will only accept email address of the EmailAddress type.

Conclusion

In this article, I have introduced the concept of primitive obsession, what problems it may cause, and how to fix them. Hopefully, you can take away some of this information and use it in your own codebase to create safer, more maintainable code.

I post mostly about full stack .NET and Vue web development (and soon maybe some more F# content!). To make sure that you don't miss out on any posts, please follow this blog and subscribe to my newsletter. If you found this post helpful, please like it and share it. You can also find me on Twitter.

Best .NET Posts This Week: 7th March 2021

Sam Walpole — Sun, 07 Mar 2021 19:41:29 +0000

Here are some of the best .NET, C# and ASP NET posts from this week.

This Weeks Articles

Five levels of performance tuning for an EF Core query

By Jon Smith

This is a companion article to the EF Core Community Standup called “Performance tuning an EF Core app” where I apply a series of performance enhancements to a demo ASP.NET Core e-commerce book selling site called the Book App. I start with 700 books, then 100,000 books and finally ½ million books.

Flurl - The elegant way to build URLs & set query params in .Net

By Kumar Ashwin Hubert

A common task when calling web apis or resources from code is building a URL and adding the necessary query string and parameters. Flurl adds extension methods to strings which helps us easily add path segment, set query params, set fragment, etc. in a clean and elegant manner.

Canceling HTTP Requests in ASP.NET Core with CancellationToken

By Marinko Spasojevic

It is quite a possible situation to have a user navigating to the client application’s page that sends an HTTP request to the server. While our app processing the request, a user can navigate away from that page. In such a case, we want to cancel the HTTP request since the response is no longer important to that user. Of course, this is just one of many situations that could happen in a real-world application where we would want to cancel our request. So, in this article, we are going to learn how to use CancellationToken to cancel HTTP requests in our client application.

"Ten++ Ways to Make Money as a Developer" eBook

A Brief Introduction to F# for Object Oriented Developers

Sam Walpole — Sat, 06 Mar 2021 12:53:43 +0000

Recently I've been learning how to write code in F#. For those who haven't heard of it, F# is Microsoft's/.NET's answer to a functional-first programming language. My motivation was to learn a functional programming language that would make coding for scientific computing and data analysis more expressive, concise, and maintainable, all while fitting seamlessly into the .NET ecosystem that I already know and love. F# fits that bill perfectly.

Why Functional Programming?

For an object oriented programmer, the idea of functional programming can be a little foreign at first. We're used to applications in which everything is an object and the application works by changing the state of those objects (mutation) over time. In contrast, functional programs consist of values and functions, and the application works by applying these functions to values in order to produce new values.

This might sound similar to methods in an object oriented style, but there are two key differences:

Values cannot be modified (they are said to be immutable). Instead, operations create and return new values.
Functions should be pure, meaning that a given input always produces the same output. This is in contrast to a class method, in which some internal state of the class might have an effect on the output of the method.

Let's have a look at this in a code example, in which we want to raise an employee's salary by a given factor:

// C# Object Oriented Example
public class Employee
{
    public string Name { get; set; }
    public float Salary { get; set; }
}

public class SalaryRaiser
{
    public float Factor { get; set; }

    public void RaiseSalary(Employee employee)
    {
        // function not pure - depends on Factor, which isn't a parameter
        var raise = employee.Salary * Factor;

        // employee object is mutated directly
        employee.Salary += raise;
    }
}

var employee = new Employee { Name = "Bob", Salary = 12345.67F };
var raiser = new SalaryRaiser { Factor = 0.05F };
raiser.RaiseSalary(employee);

// F# Functional Example
type Employee = { Name: string; Salary: float }

let factor = 0.05
let calculateSalary employee factor =
    // function is pure - factor is now a parameter
    let raise = employee.Salary * factor

    // new employee record returned
    { employee with  Salary = employee.Salary + raise }

let employee = { Name = "Bob"; Salary = 12345.67 }
let updatedEmployee = calculateSalary employee factor

The key benefits of these functional features (immutability and pure functions) is that they make your code much more maintainable and testable, since you can be sure that values aren't accidentally being mutated (also known as side-effects) and that a given function will always behave the same for a given input.

Data Types in F#

In F# data types are static and strongly typed, meaning that they are determined at compile time and a given value cannot change it's type. This will be familiar to C# programmers. However, there are some slight differences that may take some getting used to:

F# has a powerful type inference system meaning that you hardly ever have to explicitly state what the type is - it is inferred from context

// C#
public int AddInt(int a, int b)
{
    return a + b;
}

var value = AddInt(1, 2)

// F#
let addInt x y = x + y

let value = addInt 1 2

F# expects explicit conversion between types

// C#
public float AddFloat(float a, float b)
{
    return a + b;
}

int a = 1;
int b = 2;

var value = AddFloat(a, b); // ints are implicitly converted to floats

// F#
let addFloat a:float b:float = a + b // for the purpose of the example, explictly state the a and b must be floats

let value = addFloat 1 2 // will throw exception since 1 and 2 are ints

// instead
let a = float 1
let b = float 2

let value = addFloat a b

Other than this, F# contains all of the primitive data types that you will be used to in C# and many other languages.

Collections

Lists

Lists in F# are similar to those in C#, except that (because they are immutable) methods like Add/Remove do not exist. Instead, to perform the equivalent operations, new lists must be created from the existing list.

// F#

// 1. Declare a list
let list = [1;2;3] // creates a list with the elements 1, 2 and 3

// 2. Declare a list using range syntax
let list = [1..5] // create a list with the element 1, 2, 3, 4, and 5

// 3. Add an element to the start of a list
let list = [1;2;3]
let list2 = 4::list // create a list [4;1;2;3]

// 4. Remove elements from the list
let list = [1;2;3]
let list2 = list.[0..1] // returns a list containing the elements between index 0 and 1. Equivalent to removing the index 3

Sequences

Sequences are similar to lists, except they are lazily evaluated, meaning that the element values are not loaded in to memory until needed. This is useful for dealing with very large sequences. An equivalent very long list has to have all elements stored in memory simulataneously and may even crash your PC!

// F#
// large list
// WARNING: may crash your pc
let list = [1..1000000] // create a list containing 1 million elements

// large sequence
let sequence = seq {1..1000000}

Tuples

The collections we have looked at previously must contain data all with the same data type (i.e. a list of ints). A tuple is different in that it contain contain multiple values each with different data types.

// F#
// 1. declare a tuple
let myTuple = (1, "hello")

// 2. destructure a tuple
let myTuple = (1, "hello")
let (num, str) = myTuple // assigns num the value 1, and str the value "hello"

Records

Records group data into distinct objects, similar to classes. Records can even have method. However, as with most things in F#, records are immutable, so 'editing' a record requires you to create a new record from the existing one.

// F#

// 1. Declare a record type with a method
type Person = {
    Name: string; 
    Age: int;
} with member this.IsAdult = this.Age >= 18

// 2. Create a record
// Note that we don't need to tell the compiler that this is a Person record
// It can infer it from the fields we provide
let sam = { Name = "Sam"; Age = 27 }

// 3. Create a record based on an existing one
let olderSam = { sam with Age = 28 }

Discriminated Unions

Discriminated unions are a powerful feature in F# and may not be familiar to a lot of programmers - they certainly weren't to me! Discriminated unions allow values to be one of a number of named cases, each with potentially different types and values. This is probably shown that explained

// F#

// 1. Basic discriminated union
// this declares a Status type, that can have the value Active or Inactive
type Status = Active | Inactive
let myStatus = Status.Active

// 2. A more complex example
type Shape = 
    | Rectangle of width:float * length:float // takes a tuple of two floats
    | Circle of radius:float // takes a float

// both have the Shape type
let cir = Circle 5.
let rect = Rectangle(5., 6.)

Pattern Matching

Pattern matching is very common in F# and is a way of controlling the flow of the application based on the match input value. It can be likened to using if..else statements in this manner, and if statements do exist in F#, but pattern matching is far more idiomatic (and hopefully you'll agree, more powerful).

// F#

// 1. Pattern matching a discriminated union
type Status = Active | Inactive

// return true if Active, return false if inactive
let isActive status = 
    match status with
    | Active -> true
    | Inactive -> false

// 2. Pattern matching to handle errors
type Result =
    | Error of string
    | Data of int

// handle printing data or error cases to the console
let handle result = 
    match result with
    | Data data -> printfn "My result: %i" data
    | Error error -> printfn "An error ocurred: %s" error

3. Pattern matching tuple values
let matchPoint point = 
    match point with
    | (0, 0) -> printfn "This is the origin"
    | (x, 0) -> printfn "X is %i, while Y is 0" x
    | (0, y) -> printfn "Y is %i, while X is 0" y
    | _ -> printfn "Both values are non-zero" // _ is a catch all case

Some functional concepts

Currying and Partial Application

A pure function can only have one input and one output, and this is true for functions in F# as well. However, we've already seen some functions with apparently multiple parameters. For example:

let addInt x y = x + y

addInt 5 6 // evaluates to 11

Well, behind the scenes, F# is actually taking this declaration and splitting it into two separate functions, each with only one parameter. Something along the lines of:

let addInt x  =     
    let subFunction y = x + y
    subFunction 

let intermediate = addInt 5 // evaluates to a function that adds five to its parameter

intermediate 6 // evaluates to 11

This process of taking a multi-parameter function and splitting it into a pipeline of single parameter functions is called currying. This is all well and good, but what is the practical benefit for us? Well one of the interesting consequences is something called partial application.

Going back to our AddInt function in C#. It has two parameters, and you can only ever call it with two parameters. Calling it with one parameter will just lead to a compiler error.

However, if we call our addInt function in F# with just one parameter, something interesting happens. It returns a function that has our first parameter baked in! This is known as partial application, and is a highly useful concept for creating reusable pieces of code.

let addInt x y = x + y

let add5 = addInt 5 // partially apply addInt to create a new function that adds 5 to the input

add5 6 // evaluates to 11
add5 7 //evaluates to 12

Piping

Piping is a special type of operator that allows you to put the parameter to the function before the function. For example:

let addInt x y = x + y
let add5 = 5 |> addInt // pipe 5 into the addInt function

Its use may not seem immediately obvious , but it is highly useful for creating pipelines of functions, in which the output of one function feeds directly into the input of another.

[1; 2; 3] // create a list
|> List.map (fun x -> x + 1) // add 1 to each element of the list
|> List.filter (fun x -> x > 2) // only return elements that have a value greater than 2 (returns [3; 4])

Note that the expressions prefixed by fun above are simply lambda expressions (or anonymous functions) as you would see in many other languages.

Composition

Composition is the act of joining multiple functions together to create a single new function. This can seem pretty much the same as piping at first glance, but it is subtly different: a pipe has to start with a value and is immediately evaluated to give an output; function composition joins multiple functions together and returns that new function (i.e. nothing is evaluated at this stage).

// Example comparing piping and composition

let add5 = (+) 5
let double = (*) 2

// piping
5
|> add5
|> double // evaluates to 20

// composition
let add5ThenDouble = add5 >> double // compose into a new function

add5ThenDouble 5 // evaluates to 20

Conclusion

This has been my brief introduction into F# for Object Oriented Programmers. The topics I have covered are by no means exhaustive, but hopefully it is enough to whet your appetite for F# and functional programming.

For more resources F# For Fun and Profit is an excellent website and will help you dive deeper into the language.

Best .NET Posts This Week: 14th February 2021

Sam Walpole — Sun, 14 Feb 2021 14:15:03 +0000

Here are some of the best .NET, C# and ASP NET posts from this week.

This Weeks Articles

Machine Learning with ML.NET

By Nikola Zivkovic

In the previous article, we started exploring some of the basic machine learning algorithms and learned how to use ML.NET. There we covered Linear Regression, its variations and we implemented it from scratch with C#. In this article, we focus on the classification algorithm or to be more precise, the algorithms that are used primarily for classification problems. Note that we will not cover all the classification algorithms, for example, SVM and Decisions Trees, because these algorithms can be used for regression as well, so they will get separated articles just for them.

Using JS Object References in Blazor WASM to wrap JS libraries

By Kristoffer Strube

With .NET 5 Blazor WebAssembly also got a lot of great improvements. Among these are IJSObjectReferences (JavaScript Object References). These often get referenced in the changelogs and articles as JavaScript Isolation. The name indicates that this can only be used to isolate JavaScript sources similar to CSS Isolation. But IJSObjectReference can do so much more than just isolation. In this article, we will show what IJSObjectReference is and how it can be used. This article is part of our Blazor JS Wrapping series.

Security: The Principle of Least Privilege (POLP)

By Andreas Wolter

The first security principle that I am going to discuss is one that most System Administrators are familiar with: the “principle of least privilege” (short: POLP). It demands that the required permissions for a task shall only grant access to the needed information or resources that a task requires. When permissions are granted, we shall grant the least privileges possible. POLP is so crucial because initially it is the privileges that any attacker is targeting.

"Ten++ Ways to Make Money as a Developer" eBook

Best .NET Posts This Week: 7th February 2021

Sam Walpole — Sun, 07 Feb 2021 17:14:17 +0000

Here are some of the best .NET, C# and ASP NET posts from this week.

This Weeks Articles

The New .NET Multi-platform App UI

By David Ortinau

With .NET 6 previews starting right around the corner, it is time to start getting excited for the new .NET Multi-platform App UI (MAUI) that was announced at BUILD 2020. This year of .NET has a lot of amazing things for client application developers. Let’s review the highlights and set your expectations for the year ahead. .NET 6 planning and execution is happening in the open, and we have a beautiful website that summarizes our GitHub epics and user stories across all of .NET. Visit themesof.net and search on Xamarin to see the high-level details.

Dynamic method invocation with .NET Core

By David Guida

Today we’re going to explore few ways to perform “dynamic method invocation” with .NET Core. What if we have to call a method on some instance, but the only thing we know is the method signature and not the class type? It’s a tricky situation, but luckily for us, .NET has a few ways to get to the destination. The problem now is: which one is the best?

Tracing IO in .NET Core

By Jonathan Channon

I was made aware of OpenTelemetry a while ago by a blog series Jimmy Bogard and put it in my favourites to read at a later date. Of course I didn't really get back to it in depth and gave it a quick scan at the time although it is a well written in depth blog series so I suggest you do check it out. A while later I saw a blog post by Rehan Saeed which gives an introduction on what OpenTelemetry is and how it works and the concepts behind it and is definitely worth a read. At the same time I saw a YouTube video by Elton Stoneman that whilst more aimed at using tracing using Kubernetes he demonstrates a .NET app running and the tracing details appear in Jaeger.

ASP.NET Core IOptions Configuration

By Khalid Abuhakmeh

As software developers, we sure do love us some options, especially when it allows us to change application behavior without reimplementing or compiling our apps. The developer gods have carved configuration is carved into our collective developer DNA. Whether you’re new or old to ASP.NET, you’ll likely want to take advantage of settings derived from json files. In this post, we’ll explore the necessary steps required to read configuration settings from disk and the options (pun intended) to working with those values.

"Ten++ Ways to Make Money as a Developer" eBook

Build an interactive kanban board with Vue Draggable

Sam Walpole — Sun, 07 Feb 2021 09:16:49 +0000

Vue Draggable is a great library for Vue.js that makes it super simple to create interactive draggable components with virtually no effort. I have recently used it to create an interactive kanban board, in which tasks can be rearranged and moved between cards just by dragging.

So let's start by creating some reorderable cards! P.S I'm using Vuetify as the UI framework, in case the tags look unfamiliar.

<template>
  <v-container fluid>
    <v-row>
      <v-col class="text-right">
        <v-btn color="primary" depressed @click="addCard"> Add Card </v-btn>
      </v-col>
    </v-row>
    <v-row>
      <v-col v-for="(card, i) in cards" :key="i" cols="12" sm="6" md="4">
        <v-card outlined>
          <v-card-title>
            <v-text-field v-model="card.title"></v-text-field>
          </v-card-title>
        </v-card>
      </v-col>
    </v-row>
  </v-container>
</template>

<script>
export default {
  data: () => ({
    cards: []
  }),  
  methods: {
    addCard() {
      const card = {
        title: 'New Card',
        tasks: [],
      }

      this.cards.push(card)
    },
  }
}
</script>

The code above should give you the ability to create cards by clicking the Add Card button, but they aren't draggable yet. First make sure that you have VueDraggable installed by running:

yarn add vuedraggable

Then import VueDraggable into you component:

<script>
import Draggable from 'vuedraggable'

export default {
  components: {
    Draggable,
  },
  data: () => ({
    cards: []
  }),  
...

Finally, all we need to do to make the cards draggable is to wrap the cards with the draggable component. In our case, we're replacing v-row with draggable.

<draggable :list="cards" group="cards" class="row">
  <v-col v-for="(card, i) in cards" :key="i" cols="12" sm="6" md="4">
...

There are two attributes that are important to note. First, the list attribute defines the list of objects that should be draggable, in our case the cards array. Secondly, the group attribute is just a way of identifying groups of draggable components (you'll see why this is useful when we move on to creating draggable tasks).

Try running your project now. You should be able to create multiple cards, and reorder them by dragging!

Now let's move on to the tasks. Below the v-card-title tag we need to add the following code:

<v-card-text>
  <draggable :list="card.tasks" group="tasks" class="row">
    <v-col v-for="(task, j) in card.tasks" :key="j" cols="12">
      <v-text-field v-model="task.title">
        <template v-slot:append>
           <v-btn color="error" text class="ml-3" @click="deleteTask(i, j)"> Delete </v-btn>
        </template>
      </v-text-field>
    </v-col>

    <template v-slot:footer>
      <v-col cols="12">
        <v-btn color="primary" depressed block @click="addTask(card)"> Add Activity </v-btn>
      </v-col>
      <v-col cols="12">
        <v-btn color="error" text block @click="deleteCard(i)"> Delete Card </v-btn>
      </v-col>
    </template>
  </draggable>
  </v-card-text>

Add the following in the script section:

methods: {
    deleteCard(index) {
      this.cards = [...this.cards.slice(0, index), ...this.cards.slice(index + 1)]
    },
    addTask(card) {
      const task = {
        title: 'New Activity'
      }

      card.tasks.push(task)
    },
    deleteTask(cardIndex, taskIndex) {
      const card = this.cards[cardIndex]
      card.tasks = [...card.tasks.slice(0, taskIndex), ...card.tasks.slice(taskIndex + 1)]
    }
}

Here we've added the ability to add and delete tasks from each card, as well as delete the card itself. We've also added another draggable component, which wraps around each group of tasks. We've given it a group name of tasks. This is important because each list of tasks will have the same group name, meaning that we can drag tasks from one card to another! P.S. if you only wanted tasks to be reorderable within its own card, you would have to create a unique group name for each list of tasks.

And that's it! Hopefully this post has shown you how quick and easy it is to develop highly interactive draggable apps using the Vue Draggable library. What ideas will you use it for?

Conclusion

In this post I have shown you the basics of using the Vue Draggable library to create an interactive kanban board. The full repository can be found here on GitHub.

"Ten++ Ways to Make Money as a Developer" eBook

DEV Community: Sam Walpole

My Top 5 JavaScript Tips & Tricks for Writing Cleaner Code

1. Destructuring Assignment

2. Short Circuit Evaluation & Assignment

3. Optional Chaining & Nullish Coalescing Operator

4. Named Callback Functions

5. Enums/Dictionaries

Conclusion

A Practical Guide to Higher Order Functions in C#

What are higher order functions?

Practical Example - Repository Pattern

Conclusion

Looking after your mental health as a developer

Stop comparing yourself to others

Give yourself a break

Focus on now

Conclusion

LINQ: Beware of deferred execution

Benefits of Deferred Execution

1. Better Performance

2. Query Construction

3. Always revaluated

The pitfalls of deferred execution

Conclusion

Handling Dependency Injection in Inherited Classes

The Problem

The Solution - Dependency Aggregates

Conclusion

Best .NET Posts This Week: 14th March 2021

This Weeks Articles

You Might Also Like

A Cure for Primitive Obsession

What is Primitive Obsession?

Curing Primitive Obsession

Primitive Obsession in F#

Conclusion

Best .NET Posts This Week: 7th March 2021

This Weeks Articles

You Might Also Like

A Brief Introduction to F# for Object Oriented Developers

Why Functional Programming?

Data Types in F#

Collections

Lists

Sequences

Tuples

Records

Discriminated Unions

Pattern Matching

Some functional concepts

Currying and Partial Application

Piping

Composition

Conclusion

Best .NET Posts This Week: 14th February 2021

This Weeks Articles

You Might Also Like

Best .NET Posts This Week: 7th February 2021

This Weeks Articles

You Might Also Like

Build an interactive kanban board with Vue Draggable

Conclusion