DEV Community: Grant Watson

Graph Theory in C#

Grant Watson — Sat, 15 Aug 2026 16:30:51 +0000

Using graph search to solve real-world problems in C#
Most day-to-day C# work involves flat collections: filter a list, sort a table, look something up by key. Those shapes are well served by LINQ and a dictionary. But some problems are about relationships rather than records, and flat collections handle them badly.

A few examples that show up in real systems:

Which permissions does a user inherit through nested role groups?
Which build targets need to rebuild when this one file changes?
Which accounts are linked, directly or indirectly, to this flagged account?
What is the shortest referral chain between two users?
Each of these is a reachability question, and reachability is what graph search answers.

Prerequisites
Working knowledge of C# generics and collections
.NET 8 or later (the code here was compiled and run against .NET 8)
No prior graph theory is assumed. The vocabulary is small and introduced as it is needed.

The vocabulary you actually need
A graph is a set of nodes connected by edges. In an undirected graph, an edge runs both ways: if Alice and Bob are friends, each is a friend of the other. In a directed graph, edges run one way: if module A imports module B, that says nothing about B importing A.

This distinction is not academic. Getting it wrong is the single most common bug in hand-rolled graph code, and it fails silently. Your traversal returns a plausible-looking result that is missing half the graph.

Traversal means visiting nodes by following edges. Two orders dominate:

Breadth-first search (BFS) visits everything one hop away, then everything two hops away, and so on. Because it expands in rings, the first time it reaches a node it has done so by the fewest possible hops. That property makes BFS the correct choice for shortest-path-by-hop-count.
Depth-first search (DFS) follows one branch as far as it goes before backtracking. It is the natural fit for cycle detection, topological sorting, and anything that needs to know when a subtree is fully explored.
Dijkstra's algorithm and A* extend this to graphs where edges carry different costs. They are out of scope here. If your edges are all equivalent, which covers most of the cases listed above, BFS and DFS are what you want.

Representing the graph
An adjacency list is the standard representation: a map from each node to the set of nodes it connects to. Sparse graphs, which is nearly all real-world graphs, use far less memory this way than with an adjacency matrix.

Four decisions in the implementation below are worth calling out before the code:

HashSet rather than List for neighbors. Adding the same edge twice is common when ingesting data, and a list would happily store duplicates, inflating traversal work and skewing any degree calculation.
AddEdge is bidirectional by default, with an opt-out. Undirected is the more common case and the one people forget to handle, so it is the default. Directed callers pass bidirectional: false explicitly, which makes the intent visible at the call site.
Both endpoints get registered as nodes. If only the source node becomes a dictionary key, the target exists as a neighbor but has no entry of its own, and traversals starting from it return nothing.
An optional IEqualityComparer. For string nodes, case sensitivity decides whether "Alice" and "alice" are one person or two. That belongs to the caller, not the data structure.
using System;
using System.Collections.Generic;

public class Graph where T : notnull
{
private readonly Dictionary> _adjacency;

public Graph(IEqualityComparer<T>? comparer = null)
{
    Comparer = comparer ?? EqualityComparer<T>.Default;
    _adjacency = new Dictionary<T, HashSet<T>>(Comparer);
}

private IEqualityComparer<T> Comparer { get; }

public IReadOnlyCollection<T> Nodes => _adjacency.Keys;

public void AddNode(T node)
{
    if (!_adjacency.ContainsKey(node))
        _adjacency[node] = new HashSet<T>(Comparer);
}

public void AddEdge(T from, T to, bool bidirectional = true)
{
    AddNode(from);
    AddNode(to);

    _adjacency[from].Add(to);

    if (bidirectional)
        _adjacency[to].Add(from);
}

public IReadOnlySet<T> Neighbors(T node) =>
    _adjacency.TryGetValue(node, out var set)
        ? set
        : (IReadOnlySet<T>)new HashSet<T>(Comparer);

}
Breadth-first search
BFS uses a queue. Pull a node, record it, enqueue any unvisited neighbors, repeat.

The detail that matters most is when a node is marked visited. Marking on enqueue, as below, guarantees each node enters the queue exactly once. Marking on dequeue instead lets a node be enqueued several times before it is first processed, which on a dense graph degrades badly.

public List BreadthFirst(T start)
{
var order = new List();
if (!_adjacency.ContainsKey(start))
return order;

var visited = new HashSet<T>(Comparer) { start };
var queue = new Queue<T>();
queue.Enqueue(start);

while (queue.Count > 0)
{
    var node = queue.Dequeue();
    order.Add(node);

    foreach (var neighbor in _adjacency[node])
    {
        if (visited.Add(neighbor))
            queue.Enqueue(neighbor);
    }
}

return order;

}
HashSet.Add returns false when the item was already present, so the check and the insert happen in one operation rather than a Contains followed by an Add.

Depth-first search, without the recursion
DFS is usually taught recursively, and the recursive version is genuinely more readable. It is also a production hazard: the call stack depth tracks the longest path in the graph. A chain of a few hundred thousand nodes, which is unremarkable for an import graph or an org hierarchy, will throw StackOverflowException. That exception cannot be caught in .NET. The process dies.

An explicit Stack moves the frames onto the heap and removes the failure mode entirely:

public List DepthFirst(T start)
{
var order = new List();
if (!_adjacency.ContainsKey(start))
return order;

var visited = new HashSet<T>(Comparer);
var stack = new Stack<T>();
stack.Push(start);

while (stack.Count > 0)
{
    var node = stack.Pop();

    if (!visited.Add(node))
        continue;

    order.Add(node);

    foreach (var neighbor in _adjacency[node])
    {
        if (!visited.Contains(neighbor))
            stack.Push(neighbor);
    }
}

return order;

}
Note the difference from BFS: here nodes are marked visited on pop, not on push, because the same node can legitimately be pushed by several neighbors before it is reached. The if (!visited.Add(node)) continue; line absorbs those duplicates.

Finding every connected component
A connected component is a maximal set of nodes where every node is reachable from every other node in the set. Maximal matters: if you can add another reachable node to the set, it was not a component to begin with.

A single traversal finds the one component containing your start node. Finding all of them means looping over every node and starting a fresh traversal from each one not yet seen:

public List> ConnectedComponents()
{
var components = new List>();
var seen = new HashSet(Comparer);

foreach (var node in _adjacency.Keys)
{
    if (seen.Contains(node))
        continue;

    var component = BreadthFirst(node);
    components.Add(component);

    foreach (var member in component)
        seen.Add(member);
}

return components;

}
This is correct for undirected graphs only. In a directed graph, mutual reachability is a stricter condition called a strongly connected component, and plain traversal does not compute it. A directed edge A to B means BFS from A finds B, but BFS from B may never find A, so the two are not in the same SCC even though one traversal groups them. Strongly connected components need Kosaraju's or Tarjan's algorithm. Running the code above on a directed graph and calling the output "components" is a real and easy-to-miss error.

Shortest path by hop count
Because BFS reaches every node by the fewest hops, recording how you arrived at each node yields the shortest path for free. Store a cameFrom map during traversal, then walk it backwards from the goal:

public List? ShortestPath(T start, T goal)
{
if (!_adjacency.ContainsKey(start) || !_adjacency.ContainsKey(goal))
return null;

if (Comparer.Equals(start, goal))
    return new List<T> { start };

var cameFrom = new Dictionary<T, T>(Comparer);
var visited = new HashSet<T>(Comparer) { start };
var queue = new Queue<T>();
queue.Enqueue(start);

while (queue.Count > 0)
{
    var node = queue.Dequeue();

    foreach (var neighbor in _adjacency[node])
    {
        if (!visited.Add(neighbor))
            continue;

        cameFrom[neighbor] = node;

        if (Comparer.Equals(neighbor, goal))
            return Reconstruct(cameFrom, start, goal);

        queue.Enqueue(neighbor);
    }
}

return null;

}

private List Reconstruct(Dictionary cameFrom, T start, T goal)
{
var path = new List { goal };
var current = goal;

while (!Comparer.Equals(current, start))
{
    current = cameFrom[current];
    path.Add(current);
}

path.Reverse();
return path;

}
Returning null distinguishes "no path exists" from an empty result. The nullable return type forces callers to handle the disconnected case rather than discovering it at runtime.

A worked example
Nine users, two friendship clusters, and one account with no connections:

var graph = new Graph(StringComparer.OrdinalIgnoreCase);

graph.AddEdge("Alice", "Bob");
graph.AddEdge("Bob", "Carol");
graph.AddEdge("Carol", "Dave");
graph.AddEdge("Alice", "Erin");
graph.AddEdge("Erin", "Dave");

graph.AddEdge("Frank", "Grace");
graph.AddEdge("Grace", "Heidi");

graph.AddNode("Ivan");

Console.WriteLine(string.Join(" -> ", graph.BreadthFirst("Alice")));
Console.WriteLine(string.Join(" -> ", graph.DepthFirst("Alice")));

foreach (var component in graph.ConnectedComponents())
Console.WriteLine(string.Join(", ", component));

var path = graph.ShortestPath("Alice", "Dave");
Console.WriteLine(path is null ? "no path" : string.Join(" -> ", path));
Output:

Breadth-first from Alice:
Alice -> Bob -> Erin -> Carol -> Dave

Depth-first from Alice:
Alice -> Erin -> Dave -> Carol -> Bob

Connected components:
1: Alice, Bob, Erin, Carol, Dave
2: Frank, Grace, Heidi
3: Ivan

Shortest path Alice to Dave:
Alice -> Erin -> Dave (2 hops)

Shortest path Alice to Frank:
no path
Three things in that output are worth reading carefully.

Ivan appears as his own single-node component, which is correct and is a case that breaks naive implementations. Alice reaches Dave in two hops through Erin, not three through Bob and Carol, confirming BFS found the shorter of the two available routes. And Alice to Frank returns no path, because the two clusters are genuinely disconnected.

One caveat on ordering: HashSet does not guarantee enumeration order, so the relative position of same-distance siblings (Bob and Erin above) is an implementation detail and should not be asserted in tests. The distances are deterministic; the tie-breaking is not. If you need stable ordering, sort each neighbor set before enumerating.

Complexity and where it stops working
All four traversals run in O(V + E) time and O(V) space, where V is nodes and E is edges. Every node is visited once and every edge is examined once.

That is fast, and it is also the ceiling. The practical limits:

Memory is the binding constraint. O(V) for the visited set plus the adjacency structure itself means the whole graph lives in RAM. Somewhere in the low millions of nodes, depending on T, this stops being viable in a single process.
BFS peak queue size scales with the widest level. On a graph with high fan-out, such as a follower network with celebrity accounts, the queue can hold a large fraction of all nodes at once. The average case looks fine and the worst case does not.
Repeated queries recompute everything. If you are answering the same reachability question against a slow-changing graph many times, cache the components rather than re-traversing.
Weighted edges need different algorithms. The moment edges carry costs, BFS gives you the fewest-hops path, which is not the cheapest path. That is Dijkstra's territory.
Cycles, worth noting, are not a problem here. The visited set handles them by construction. Cyclic graphs terminate correctly:

Cyclic graph BFS from 1: 1 -> 2 -> 3
Cycles only cause infinite loops in implementations that omit visit tracking, which is why the visited set is present from the first version rather than added as an optimization.

When to use a library instead
The code above is roughly 120 lines and it is worth writing yourself when the graph is a small part of a larger system, when you want no extra dependency, or when you are learning the algorithms.

Reach for QuikGraph instead when you need weighted algorithms, topological sort, minimum spanning trees, maximum flow, or graph serialization. Reimplementing Dijkstra correctly, including the priority queue behavior, is more error-prone than most people expect.

If the graph is the system rather than a component of it, and especially if it needs to be queried and persisted, a graph database such as Neo4j is a better fit than any in-process structure.

Summary
The four operations above cover a large share of practical graph work in C#: BFS for shortest hops, DFS for exhaustive exploration, component detection for clustering, and path reconstruction for explaining a result. The implementation is small enough to read in one sitting and to test thoroughly.

The failure modes to watch are the quiet ones. Directed edges where you assumed undirected, recursion depth on long chains, and calling a directed traversal result a connected component. None of the three throws an exception. All three produce answers that look reasonable and are wrong.

Implementing CORS in ASP.NET Core Applications

Grant Watson — Sat, 27 Jun 2026 23:00:33 +0000

This and all my other articles can be found at GWS Blog

As web developers, we're familiar with the challenges of cross-origin resource sharing (CORS). In this guide, we'll show you how to implement CORS in ASP.NET Core applications, ensuring your API is secure and accessible to clients from different domains.

Prerequisites

.NET 6.0 or later
Visual Studio Code or your preferred IDE
The Microsoft.AspNetCore.Http NuGet package (installed via the Package Manager Console)

Introduction

CORS allows web servers to specify which domains are allowed to access their resources, preventing cross-site scripting (XSS) attacks and ensuring data integrity. In this guide, we'll walk you through implementing CORS in ASP.NET Core.

Configuring CORS

To enable CORS in your ASP.NET Core application, create a new instance of the CorsOptions class:

var corsOptions = new CorsOptions();

Next, configure the AllowAnyOrigin, Allow Any Method, and AllowAnyHeaders properties to control which origins, methods, and headers are allowed:

corsOptions.AllowAnyOrigin = true;
corsOptions.AllowAnyMethod = true;
corsOptions.AllowAnyHeader = true;

app.UseCors(corsOptions);

Alternatively, you can configure CORS using a policy file (cors-policies.json):

{
  "AllowAnyOrigin": true,
  "AllowAnyMethod": true,
  "AllowAnyHeader": true
}

Common Pitfalls and Edge Cases

Handling preflight requests: When setting options for a request that is not allowed by the browser, it should include an Origin header. The server must respond with the correct headers to allow the browser to make the actual request.
```
app.UseCors(options =>
{
options.WithOptions();
});
```
csharp
Configuring allowed origins: By default, only origins specified in the policy are allowed. To include wildcard domains (e.g., *.example.com), use the AllowAnyOrigin property:

corsOptions.AllowAnyOrigin = "*";

However, be cautious when using this approach as it may increase security risks.

Error handling: Implement error handling to catch and handle CORS-related errors. You can use a custom exception handler or a middleware that handles exceptions:

app.UseExceptionHandler(ex => ex.Run(async context =>
{
  var exception = context.Exception;
  // Handle the exception
}));

Alternatively, you can use the built-in `System.Web.HttpException` class to create a CORS-related exception.

Logging and monitoring: Implement logging and monitoring mechanisms to track CORS-related requests and errors. This will help you identify potential security issues and improve your application's overall security posture.

Recap

In this guide, we covered implementing CORS in ASP.NET Core applications using the CorsOptions class and configuring CORS policies using a policy file. We also discussed common pitfalls and edge cases to ensure your application is secure and accessible to clients from different domains.

Remember to always verify that your implementation aligns with best practices and industry standards. Always consult official documentation and reputable sources for guidance on implementing security measures in your applications.

React Performance for Senior Developers (Practical, No Cargo Culting)

Grant Watson — Fri, 01 May 2026 16:03:10 +0000

👉 Read the full article on my site

📚 Browse all my articles

Author: Grant Watson

Published: 2026-02-21

Category: React / Frontend Performance

Recommended Deals

👉 Claim a Book-A-Million 15% coupon here

The performance mindset (the part people skip)

Performance work fails for three reasons:

No baseline (you never proved it was slow)
Wrong bottleneck (you optimized the wrong layer)
No regression protection (you fixed it once and it came back)

Process: measure → isolate → fix highest leverage → add guardrails

1) Measure first: React Profiler + why-did-you-render

What to look for in the Profiler

Commit duration
Which components re-rendered
Why they re-rendered
Frequency vs cost

Optimize frequency first, then cost.

Render counter hook

import { useEffect, useRef } from "react";

export function useRenderCount(name) {
  const count = useRef(0);
  count.current++;

  useEffect(() => {
    console.log(`[render] ${name}: ${count.current}`);
  });
}

2) The #1 cause of slow apps: unnecessary re-renders

Problem: unstable props

function Page() {
  const filters = { status: "active" };
  const onRowClick = (id) => setSelected(id);

  return <Table filters={filters} onRowClick={onRowClick} />;
}

Fix: stabilize identity when it matters

const filters = useMemo(() => ({ status: "active" }), []);
const onRowClick = useCallback((id) => setSelected(id), []);

Memo hooks are identity stabilizers, not magic speed boosts.

3) React.memo: use it on expensive components

const Row = React.memo(function Row({ item, onClick }) {
  return (
    <div onClick={() => onClick(item.id)}>
      {item.name} — {item.status}
    </div>
  );
});

Memo only works if the props are stable.

4) State architecture: colocate hot state

Problem

function App() {
  const [form, setForm] = useState({ ... });

  return (
    <>
      <Sidebar form={form} />
      <Main form={form} />
      <Preview form={form} />
    </>
  );
}

Fix

function Main() {
  const [form, setForm] = useState({ ... });

  return (
    <>
      <Form form={form} setForm={setForm} />
      <Preview form={form} />
    </>
  );
}

Keep frequently changing state deep.

5) Lists: virtualization beats memo spam

npm i react-window

import { FixedSizeList as List } from "react-window";

function VirtualizedUsers({ users }) {
  return (
    <List
      height={600}
      itemCount={users.length}
      itemSize={44}
      width="100%"
      itemData={users}
    >
      {Row}
    </List>
  );
}

High ROI change: fewer DOM nodes, less layout, less memory.

6) Memoize derived data

const rows = useMemo(() => {
  return data.map(x => ({ ...x, computed: expensive(x) }));
}, [data]);

Or use select in TanStack Query.

7) Avoid context re-render storms

Problem

<AppContext.Provider value={{ user, theme, locale, flags }}>
  <BigTree />
</AppContext.Provider>

Fix: split contexts

<UserContext.Provider value={user}>
  <ThemeContext.Provider value={theme}>
    <LocaleContext.Provider value={locale}>
      <BigTree />
    </LocaleContext.Provider>
  </ThemeContext.Provider>
</UserContext.Provider>

8) Concurrent React: keep typing responsive

const [query, setQuery] = useState("");
const [filter, setFilter] = useState("");
const [isPending, startTransition] = useTransition();

<input
  value={query}
  onChange={(e) => {
    const next = e.target.value;
    setQuery(next);
    startTransition(() => setFilter(next));
  }}
/>

Users care about input responsiveness more than filter latency.

9) Bundle performance matters

Code split heavy routes

const AdminPanel = lazy(() => import("./AdminPanel"));

Dynamic import heavy utilities

const { jsPDF } = await import("jspdf");

If it’s not needed on first paint, don’t ship it.

10) Images: silent performance killers

Best practices:

Responsive sizes
AVIF/WebP
Lazy load below the fold
Set width/height to prevent CLS

<img
  src={src}
  width={800}
  height={450}
  loading="lazy"
  decoding="async"
  alt="..."
/>

11) Guardrails against regressions

Track bundle size in CI
Add render sanity checks for critical screens
Don’t ship multi‑MB JS for simple views

The practical checklist

Profile first
Fix frequency re-renders
Virtualize large lists
Split contexts and colocate hot state
Code split heavy bundles
Add guardrails

Performance is a process, not a one-time refactor.

How to Identify and Remove Code Smells in Modern Codebases

Grant Watson — Fri, 01 May 2026 15:54:01 +0000

Code Smells in Real-World Systems: How to Identify, Prioritize, and Eliminate Them Without Slowing Your Team Down

Continue Reading

If you want the full deep dive with expanded examples and breakdowns:

👉 Read the complete article here

Looking for more content like this?

📚 Explore all articles on grantwatson.dev

Introduction: When “Working Code” Becomes the Problem

Every engineer has worked in a system that technically works—but feels hostile.

You open a file to fix a small bug and realize:

The method is 200 lines long
You need to understand three unrelated concerns
Changing one line might break something you don’t fully understand

So you hesitate. You move slower. You over-test. You double-check everything.

Nothing is broken. But everything is expensive.

That’s the real impact of code smells.

They don’t show up in logs. They don’t trigger alerts. They don’t crash your app.

They quietly erode your ability to change the system.

And over time, that erosion becomes the defining characteristic of the codebase.

This article is not about textbook definitions. It is about what actually happens inside production systems—and how experienced engineers deal with it.

Recommended Gear Deal

Oakley Clearance: Up to 50% Off Selected Products + Free Shipping

If you’re looking for performance eyewear, outdoor gear, or everyday Oakley products, this promotion is worth checking while it is active.

View Oakley Clearance Deals →

Explore More Oakley Products →

Affiliate disclosure: This article may contain affiliate links. If you purchase through these links, I may earn a commission at no additional cost to you.

What Code Smells Actually Are

Code smells are not bugs.

They are signals.

They indicate that the structure of the code is working against you—even if the behavior is correct.

A helpful way to think about it:

A bug is a failure of correctness
A code smell is a failure of design

You can ship code with smells. Teams do it every day.

But each smell increases the cost of the next change.

That’s why experienced engineers care. Not because the code is “ugly,” but because it is becoming harder to evolve.

The Real Cost of Code Smells in Production

In isolation, most smells are harmless. The problem is how they interact.

A long method by itself is manageable.

A long method that is duplicated, poorly named, and tightly coupled becomes dangerous.

Now every change requires:

Understanding multiple responsibilities at once
Modifying logic in multiple places
Risking side effects in unrelated areas

This shows up in very real ways:

A “simple change” takes half a day instead of 30 minutes
A bug fix introduces a regression somewhere else
Pull requests get larger because nothing is isolated
New developers avoid touching certain files

At that point, the system is not just complex—it is resisting change.

The Safe Refactoring Loop (What Actually Works)

Refactoring advice often sounds simple: “make small changes.”

In practice, it’s constrained by deadlines, missing tests, and incomplete understanding.

A realistic refactoring loop looks like this:

Identify the smell

Not every imperfection matters. Focus on code that is actively causing friction.
Understand current behavior

Before changing structure, understand what the code actually does—not what you think it does.
Stabilize behavior (tests or observation)

If tests exist, use them.

If they don’t, create lightweight checks—logs, manual verification, or characterization tests.
Refactor in small, reversible steps

Extract a method. Rename a variable. Introduce a boundary.

Avoid large, sweeping changes.
Validate constantly

After every change, confirm behavior is preserved.

This loop is not about perfection. It is about controlled improvement.

Deep Dive: The Most Dangerous Code Smells

Long Methods

Long methods are rarely intentional. They accumulate.

A method starts small. A feature gets added. Then another. Over time, unrelated concerns end up in the same place.

Before

public async Task ProcessOrderAsync(Order order)
{
    if (order == null) throw new ArgumentNullException();

    if (order.Total > 100)
    {
        order.Discount = 10;
    }

    _db.Orders.Add(order);
    await _db.SaveChangesAsync();

    await _emailService.SendAsync(order.CustomerEmail);
}

What’s Actually Wrong

This method combines:

Validation
Business rules
Persistence
External communication

Each of these evolves independently. Keeping them together creates friction.

After

public async Task ProcessOrderAsync(Order order)
{
    Validate(order);
    ApplyDiscount(order);
    await SaveAsync(order);
    await NotifyAsync(order);
}

The improvement isn’t cosmetic. It reduces cognitive load.

A developer can now understand the method in seconds instead of minutes.

God Classes

God classes form when teams prioritize convenience over boundaries.

Instead of creating a new component, functionality is added to an existing service.

Before

public class TicketService
{
    public Task Create() {}
    public Task Update() {}
    public Task SendEmail() {}
    public Task ExportReport() {}
}

Problem

This class owns multiple responsibilities:

Domain logic
Notifications
Reporting

Each has different change patterns.

After

public class TicketService {}
public class TicketNotificationService {}
public class TicketReportingService {}

This reduces coupling and allows independent evolution.

Duplicate Logic

Duplication is rarely intentional. It’s usually the fastest path under pressure.

Before

if (total > 500) return total * 0.1m;

Repeated across the codebase.

Problem

Now the discount rule exists in multiple places.

Change the rule once, and you risk inconsistency.

After

private decimal CalculateDiscount(decimal total)
{
    return total > 500 ? total * 0.1m : total * 0.05m;
}

One rule. One place. Predictable behavior.

Primitive Obsession

Using primitives for everything feels simple—but it removes constraints.

Before

public string Status;

Problem

Nothing prevents invalid values.

After

public enum Status
{
    Active,
    Inactive
}

Types communicate intent and enforce rules at compile time.

Long Parameter Lists

Before

CreateUser(string first, string last, string email, string phone)

Problem

Hard to read, easy to misuse, difficult to extend.

After

CreateUser(CreateUserRequest request)

Grouping related data reduces complexity and improves clarity.

Boolean Flags

Before

SaveOrder(order, true);

Problem

The meaning of “true” is implicit.

After

SaveOrder(order);
SaveOrderAndNotify(order);

Explicit methods remove ambiguity and reduce misuse.

Deep Nesting

Before

if (a)
{
    if (b)
    {
        if (c)
        {
        }
    }
}

Problem

Understanding requires tracking multiple conditions simultaneously.

After

if (!a || !b || !c) return;

Flattening logic reduces mental overhead.

Tight Coupling

Before

var emailService = new EmailService();

Problem

The class is tied to a specific implementation.

After

public MyService(IEmailService emailService)

This enables testing, flexibility, and replacement.

Poor Naming

Names are the primary way developers understand code.

Before

var d = GetData();

After

var activeOrders = GetActiveCustomerOrders();

Good naming removes the need for explanation.

Comment-Driven Code

Comments often compensate for unclear code.

Before

// check if active
if (user.Status == "A")

After

if (user.IsActive)

Clear code eliminates the need for explanatory comments.

Repository-Level Code Smells

Most articles stop at code. Real problems often exist at the repository level.

Common patterns:

No consistent architecture
Mixed concerns across folders
Configuration scattered across files
No CI enforcement

These issues affect the entire team—not just individual files.

A well-structured repository reduces friction at scale.

How to Prioritize Code Smells

Trying to fix everything is a mistake.

Focus on:

Code you are actively modifying
Areas with frequent bugs
High-complexity modules

This approach—often called “refactor where you touch”—keeps progress continuous without slowing delivery.

Tooling (And Its Limits)

Tools like SonarQube, Roslyn analyzers, and ESLint help identify issues.

But tools do not understand context.

They can flag:

Long methods
Complexity
Duplication

They cannot decide:

Whether a refactor is worth the cost
Whether a smell is intentional
Whether the system’s behavior is preserved

Tools assist. Engineers decide.

Code Review Checklist

When reviewing code, ask:

Can I understand this quickly?
Does this method do one thing?
Is logic duplicated?
Are names meaningful?
Is behavior obvious without comments?

If not, the code needs work.

Common Refactoring Mistakes

Refactoring without understanding behavior
Large, risky pull requests
Introducing abstractions too early
Cleaning code without addressing underlying problems

Refactoring is not about making code look better.

It is about making it easier to change.

Conclusion

Clean code is often misunderstood as an aesthetic pursuit—something subjective, even optional. In reality, it is a discipline rooted in economics and risk management. The structure of your codebase determines how quickly your team can respond to change, how confidently you can deploy, and how effectively new engineers can contribute. Poor structure introduces friction; over time, that friction compounds into hesitation, workarounds, and ultimately stagnation.

The goal is not to eliminate every imperfection. That mindset leads to over-engineering and missed deadlines. Instead, the objective is to continuously reduce unnecessary complexity in the areas that matter most—where your system is evolving, where your business logic lives, and where your team spends the majority of its time. Small, deliberate improvements create leverage. They make future changes cheaper, safer, and faster.

Refactoring, done correctly, is not a rewrite. It is a series of controlled, behavior-preserving decisions that improve clarity and isolate responsibility. It requires discipline, judgment, and restraint. Most importantly, it requires an understanding that today’s shortcuts become tomorrow’s constraints.

The best engineering teams are not those who write perfect code. They are the ones who consistently make their code easier to work with.

Leave the code better than you found it. Clean code is not clever code. It is code that allows change without fear.

Applied consistently, that principle transforms not just codebases—but the way teams build software.

Earned Complexity: A Disciplined, Evidence-Based Framework

Grant Watson — Mon, 19 Jan 2026 01:10:28 +0000

Abstract

Modern software engineering organizations increasingly struggle not because of insufficient technical skill or innovation, but due to a systemic over-accumulation of complexity that is introduced faster than it can be justified, understood, governed, or operated. This phenomenon—often mislabeled as technical ambition, future-proofing, or scalability planning—has been repeatedly identified as a root cause of degraded system reliability, declining delivery velocity, organizational burnout, and unsustainable maintenance cost.

This paper formalizes Earned Complexity, an evidence-based decision framework designed explicitly for software teams to determine when architectural or systemic complexity is warranted and how such complexity must be constrained, monitored, and revisited over time. The framework synthesizes principles from well-established engineering literature, including Choose Boring Technology, You Are Not Google, and the maxim Code Is Read More Than It Is Written, alongside operational insights from reliability engineering, systems thinking, and organizational psychology.

By reframing complexity as a scarce resource that must be earned and continuously paid for, this work proposes a practical, repeatable discipline that aligns technical decision-making with long-term organizational performance. The intended outcome is not minimalism for its own sake, but sustained peak execution through disciplined restraint.

1. Introduction: Why Complexity Requires Study

Software systems do not fail randomly. They fail predictably, following well-understood patterns associated with unmanaged complexity: cascading failures, brittle abstractions, opaque behavior, and disproportionate operational overhead. Despite decades of industry experience, many teams continue to repeat the same mistakes, introducing advanced architectures prematurely and assuming that sophistication is synonymous with professionalism.

The study of complexity in software engineering is not new. Brooks’ No Silver Bullet established early that essential complexity cannot be eliminated, only managed ¹. However, modern development practices—cloud infrastructure, distributed systems, and rapidly evolving frameworks—have dramatically lowered the activation energy required to introduce complexity, while simultaneously increasing the cost of operating it.

This asymmetry has created an environment in which teams can add complexity far more easily than they can remove it.

The motivation for this study is therefore pragmatic: how can software teams systematically distinguish between necessary complexity and optional complexity, and how can they govern the latter to prevent long-term harm?

2. Intellectual Origins of Earned Complexity

2.1 Choose Boring Technology

Dan McKinley’s essay Choose Boring Technology articulates a central insight: most business problems do not require novel solutions, and novelty disproportionately increases risk relative to its benefit. McKinley argues that mature organizations succeed not by adopting cutting-edge tools, but by selecting technologies that are well-understood, widely supported, and operationally predictable.

“If the problem you are solving is not unique, your solution should probably not be either.”

— McKinley, Choose Boring Technology

https://mcfunley.com/choose-boring-technology

This work establishes the foundational idea that engineering maturity manifests as restraint, not maximal sophistication.

2.2 You Are Not Google

The essay commonly referred to as You Are Not Google (popularized through multiple iterations and talks) critiques the widespread tendency for organizations to emulate the architectures of hyperscale technology companies without possessing the corresponding scale, staffing, or operational maturity.

The key contribution of this perspective is the concept of scale proportionality: architectural decisions must be justified by actual constraints, not aspirational ones.

“Premature scaling is just another form of premature optimization.”

https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb

This work directly informs the Evidence Gate in the Earned Complexity framework.

2.3 Code Is Read More Than It Is Written

The assertion that code is read more than it is written reframes software as a long-lived communicative artifact rather than a short-lived construction task. While often attributed informally, this principle is supported by empirical research showing that maintenance accounts for the majority of software lifecycle cost ².

Readable, predictable code reduces onboarding time, error rates, and recovery time during incidents. Conversely, clever or opaque implementations amplify cognitive load and slow organizational response.

This principle informs the framework’s emphasis on cognitive cost as a first-class consideration.

3. Complexity as an Organizational Liability

Complexity introduces costs that are frequently underestimated or ignored during design discussions. These costs fall into four primary categories:

Cognitive Load – The mental effort required to understand, modify, and debug a system.
Operational Load – The ongoing effort required to deploy, monitor, and recover the system.
Failure Surface Area – The number of distinct ways a system can fail, including partial or silent failures.
Dependency Risk – The fragility introduced by external libraries, platforms, vendors, or coordination mechanisms.

Importantly, these costs compound over time. Each additional layer of abstraction increases the difficulty of future changes, often non-linearly.

Research in systems engineering consistently demonstrates that increased system complexity correlates with decreased reliability unless mitigated by proportional investment in controls and expertise ³.

4. The Law of Earned Complexity

Complexity must be earned by measurable pain, and paid for with controls.

This law formalizes two necessary conditions:

Justification Condition: A demonstrable, current problem exists that cannot be addressed through simpler means.
Governance Condition: The organization is willing and able to fund the mechanisms required to safely operate the added complexity.

If either condition is unmet, complexity should not be introduced.

5. The Earned Complexity Framework

5.1 Gate 0: Problem Definition

Teams must articulate proposed complexity in a single sentence:

“We propose adding X to address Y, measured by Z, with rollback R.”

This constraint enforces clarity and prevents ambiguity-driven scope creep.

5.2 Gate 1: Evidence of Pain

Acceptable evidence includes:

Recurrent production incidents
SLO or error-budget violations
Quantified performance ceilings
Measured delivery bottlenecks
Documented compliance requirements

Speculative future needs are explicitly excluded.

5.3 Gate 2: Alternatives Analysis

Teams must demonstrate that:

Procedural remedies were attempted
Localized technical optimizations were evaluated
Architectural escalation is unavoidable

This step enforces graduated response.

5.4 Gate 3: Cost Modeling

Each proposal is scored across four dimensions (0–5):

Cognitive Load
Operational Load
Failure Modes
Dependency Risk

Total Cost Score: 0–20

5.5 Gate 4: Benefit Modeling

Benefits are similarly scored:

Reliability Improvement
Performance or Cost Efficiency
Delivery Velocity
Security or Compliance Risk Reduction

Total Benefit Score: 0–20

5.6 Gate 5: Controls Requirement

Complexity must ship with:

Observability (metrics, logs, traces)
Alerting aligned to user impact
Rollback and kill-switch mechanisms
Named ownership and runbooks
Failure-mode testing
A stated complexity budget

6. Decision Rule

Complexity may be approved only if:

Evidence and Alternatives gates pass, and
Benefit − Cost ≥ +4, or
Compliance mandates the change and controls are funded

Otherwise, the proposal is rejected or deferred.

7. Practical Team Applications

7.1 Architecture Reviews

Replace subjective debates with structured scoring and evidence review.

7.2 Code Reviews

Use the framework to challenge unnecessary abstractions early.

7.3 Incident Retrospectives

Tie complexity reduction directly to incident prevention.

7.4 Engineering Governance

Adopt Earned Complexity as a formal policy or ADR requirement.

8. Case Study: Microservices Adoption

A mid-sized team experiencing deployment conflicts considered migrating to microservices.

Evidence: No scaling constraints, no incident correlation
Alternatives: Modular monolith not attempted
Cost: High operational and cognitive load
Decision: Rejected

Outcome: Delivery velocity improved after refactoring boundaries without architectural escalation.

9. Sustaining Peak Performance

Peak engineering performance is not achieved through maximal output or technical bravado. It emerges from predictable systems, calm operations, and disciplined decision-making.

Earned Complexity provides teams with a repeatable mechanism to protect these outcomes.

10. Conclusion

Complexity is neither inherently good nor bad. It is expensive. Like any scarce organizational resource, it must be justified, governed, and revisited.

By adopting Earned Complexity as a formal discipline, software teams can align technical ambition with operational reality—achieving sustainable excellence without unnecessary risk.

References

https://ieeexplore.ieee.org/document/1663532

Brooks, F. P. (1987). No Silver Bullet—Essence and Accidents of Software Engineering. IEEE Computer. ↩
Lehman, M. M. (1980). Programs, Life Cycles, and Laws of Software Evolution. Proceedings of the IEEE. ↩
Perrow, C. (1984). Normal Accidents: Living with High-Risk Technologies. Basic Books. ↩

12 Powerful React Libraries Every Developer Should Master in 2025

Grant Watson — Mon, 21 Jul 2025 16:52:21 +0000

12 Powerful React Libraries Every Developer Should Master in 2025

React continues to lead the frontend world in 2025, but with its simplicity comes the challenge of choosing the right tools. Whether you're a solo developer or working on a team, these 12 libraries will help you work faster, write better code, and build more dynamic web apps.

1. React Router

What it does: Declarative routing for single-page React apps.

React Router is still the industry standard for managing routes in React. It supports nested layouts, lazy loading, and dynamic route parameters.

👉 Documentation

2. Zustand

What it does: Minimal state management using hooks.

Zustand is gaining popularity for being tiny, fast, and avoiding boilerplate. It works great for global state in small-to-medium apps.

👉 Documentation

3. React Hook Form

What it does: Performant, hook-based form management.

React Hook Form simplifies validation and reduces re-renders in complex forms. It’s a must-have for building accessible, fast forms.

👉 Documentation

4. TanStack Query (React Query)

What it does: Fetch, cache, and sync server state.

React Query (now TanStack Query) helps you manage API requests with automatic caching, background updates, and retry logic.

👉 Documentation

5. Framer Motion

What it does: Declarative animations for React.

Framer Motion is a high-performance library for creating animations, gestures, and transitions without writing CSS keyframes.

👉 Documentation

6. React Helmet

What it does: Control your document’s <head>.

React Helmet lets you dynamically set meta tags, page titles, and social tags—essential for SEO in single-page apps.

👉 Documentation

7. React Markdown

What it does: Render Markdown content as React components.

Perfect for blogs, docs, or CMS-driven sites where content is stored in Markdown. It supports plugins like remark-gfm.

👉 Documentation

8. React Testing Library

What it does: Tests components like a user would interact with them.

It encourages good testing practices by focusing on user behavior, not implementation details.

👉 Documentation

9. Recharts

What it does: Charting with React components.

If you need bar, line, or pie charts quickly without dealing with D3 directly, Recharts is clean and customizable.

👉 Documentation

10. Formik

What it does: Form state management with validation support.

Formik provides a structured way to handle form inputs, validation, and submission logic—often used with Yup.

👉 Documentation

11. React Icons

What it does: Use icon packs (FontAwesome, Material, etc.) as components.

React Icons makes it easy to import and style only the icons you need. Works great with Tailwind and other styling libraries.

👉 Documentation

12. React DnD

What it does: Drag-and-drop interface with full control.

Built by the React community, this gives you precise control over draggable interfaces like Kanban boards.

👉 Documentation

💡 Final Thoughts

The React ecosystem is thriving, but that also means constant change. The libraries above are ones you can trust—actively maintained, battle-tested, and developer-friendly.

Save this post, revisit it throughout the year, and let me know which libraries you’re using in production!

📝 Originally published at grantwatson.dev/blog

Mastering Automation: 5 Real-World n8n Workflow Examples (With Step-by-Step Guides)

Grant Watson — Mon, 21 Jul 2025 16:42:09 +0000

Mastering Automation: 5 Real-World n8n Workflow Examples (With Step-by-Step Guides)

This and other articles of mine can be found here

📌 Overview

n8n is an open-source workflow automation tool that allows you to connect services (APIs, webhooks, databases, CRMs, and more) into powerful automations without writing boilerplate glue code. Whether you're a beginner or seasoned power user, this article provides 5 comprehensive, real-world workflows to launch your n8n journey or deepen your automation chops.

Each example includes:

Use case breakdown
Step-by-step setup
Real-world benefits
JSON download (optional)

🔧 Prerequisites

Before diving in:

Install n8n (self-hosted Docker or cloud-based)
Have credentials ready (e.g., Gmail, Notion, GitHub)
Know how to use the n8n Editor UI

🧠 Workflow 1: Automatic Lead Collection from Typeform to Notion CRM

💡 Use Case

You want to capture leads from a Typeform form and store them in your Notion CRM database automatically.

🧱 Tools

Trigger: Typeform Trigger
Action: Notion node (Database row creation)
Optional: Email confirmation via Gmail

🛠 Step-by-Step

Create a Typeform with fields like Name, Email, Company.
In n8n:
- Add Typeform Trigger → Select your form
- Add Notion node:
  - Choose your database
  - Map answers.fields from Typeform to Notion properties
- (Optional) Add Gmail node to email the lead a thank-you note.

✅ Real-World Impact

Eliminates manual copy-pasting.
Keeps your CRM always up-to-date.
Saves time for your sales team.

🗓 Workflow 2: Google Calendar Event → Slack Notification + Mattermost Alert

💡 Use Case

Notify your team in both Slack and Mattermost whenever a new calendar event is added.

🧱 Tools

Trigger: Google Calendar node (polling)
Actions: Slack, Mattermost

🛠 Step-by-Step

Add Google Calendar node (polling every 10 minutes)
Use Slack node:
- Format: "New Event: {{summary}} at {{start}}"
Add Mattermost node:
- Webhook URL
- Use same message template

✅ Real-World Impact

Ensures every team member is notified, no matter their preferred chat app.
Prevents missed meetings.

📝 Workflow 3: GitHub Issue → Create Jira Ticket → Email Developer

💡 Use Case

New GitHub issues automatically create Jira tasks and notify the assigned dev by email.

🧱 Tools

Trigger: GitHub (Webhook)
Actions: Jira Software, Gmail

🛠 Step-by-Step

Add GitHub Trigger → Connect webhook to repo
Use Jira node to create an issue:
- Project, Summary, Description from GitHub payload
Use Gmail node:
- Subject: New Issue Assigned: {{issue.title}}
- Body: Include GitHub and Jira links

✅ Real-World Impact

DevOps automation: from bug discovery to tracking in one sweep.
Instant communication loop.

🧾 Workflow 4: Daily Digest of New RSS Articles to Email

💡 Use Case

Receive a curated daily email of tech news articles from multiple RSS feeds.

🧱 Tools

Trigger: Schedule (Daily)
Actions: Multiple RSS Feed nodes, Merge, Gmail

🛠 Step-by-Step

Add Schedule node: daily at 8 AM
Add multiple RSS Feed Read nodes (e.g., Ars Technica, Hacker News, TechCrunch)
Merge them using Merge node (combine mode)
Use Set node to format email body with titles + links
Send email via Gmail

✅ Real-World Impact

Daily inbox summaries, no feed bloat.
Saves hours of scrolling.

🧮 Workflow 5: Auto Backup New Notion Pages to Google Drive as Markdown

💡 Use Case

When a new page is created in Notion, export and save it as a Markdown file on Google Drive.

🧱 Tools

Trigger: Notion Trigger
Actions: Notion → HTTP node (for Markdown conversion), Google Drive

🛠 Step-by-Step

Add Notion Trigger for new pages in a workspace
Retrieve content using Notion Content node
Use HTTP node to convert content to Markdown (or use JS function to clean format)
Save the .md file using Google Drive upload node

✅ Real-World Impact

Version-controlled documentation.
Local backups for regulatory or compliance reasons.

🧩 Bonus Ideas for Advanced Users

Use Case	Tools
Auto-post job listings from RSS to LinkedIn	RSS → HTTP (LinkedIn API)
Daily DB backup to S3	PostgreSQL node → AWS S3
Sync rows between Airtable & Google Sheets	Airtable → Google Sheets
ChatGPT Summarizer for new YouTube uploads	YouTube → HTTP (OpenAI) → Email
Trigger webhook from Mattermost slash command	Webhook → Custom Logic → Response

📥 Best Practices for Workflow Building

Use Namespaces – Name every node clearly (getIssueDetails, sendSlackAlert)
Group with Notes – Add descriptive notes to each logic block.
Error Handling – Use the Error Trigger to catch and report errors.
Version Control – Export workflows as JSON to Gitea or GitHub.
Security – Never expose credentials in plain text. Use secrets and environment variables.

🎓 Where to Learn More

🧠 Final Thoughts

n8n is more than just a no-code tool—it's a logic engine that empowers creators, developers, and teams to build tailored automations that match their workflows precisely. Whether you’re building a SaaS platform, syncing internal tools, or just automating your morning, these workflows give you a strong launchpad.

Save this article. Build from these. Then go create something remarkable.

Sell Yourself as a Developer: Creating a Personal Brand That Stands Out

Grant Watson — Tue, 27 May 2025 22:37:47 +0000

In a world full of portfolios, GitHub profiles, and online résumés, it’s easy to feel like one developer in a sea of sameness. But here’s the truth: if you want better opportunities, better projects, and more control over your career—you need to sell yourself. And that starts with a personal brand.

You might think “branding” is just for influencers and startups. Not true. As a developer, your brand is your reputation made visible.

Here’s how to build it, own it, and let it open doors.

⸻

🧭 Know What You Want to Be Known For

Before you can create a personal brand, you need clarity. Ask yourself:
• What kind of problems do I love solving?
• Which technologies excite me most?
• Do I want to be known for front-end creativity, backend mastery, architecture, teaching, or something else?

Your brand should be a reflection of both your skills and your passions. You can’t be the “everything” dev. Be the dev people remember for something specific.

⸻

🌐 Build a Home for Your Work

Every strong brand needs a place to live. For developers, this is your personal website or blog. It should include:
• A clean, focused portfolio with 2–4 strong projects
• A professional “About Me” section that shows personality and clarity
• Links to your GitHub, LinkedIn, Twitter, and blog

If you want bonus points? Add a blog. Write about the things you’re learning or building. Teach what you know. It reinforces your brand and builds trust.

Developers who blog consistently get noticed. Not just for what they build, but for how they think.

⸻

📣 Talk About What You Do (Even If No One’s Listening Yet)

Share progress on Twitter, LinkedIn, or dev communities. You don’t need to have a massive audience—you’re documenting your journey for future you and for the one person watching who might open a door.
• Share a cool solution to a problem you hit
• Post a demo or screenshot of a feature in progress
• Reflect on a challenge and how you overcame it

This isn’t bragging. It’s visibility.

⸻

💼 LinkedIn and GitHub: Signal vs. Noise

Too many developers ignore or underuse these platforms.

LinkedIn:
• Keep your headline crisp: “C# Backend Developer | Blazor + .NET Enthusiast” is better than “Software Engineer.”
• Fill out your “About” with what you do best and what you want next
• Share articles, comment on posts, be visible

GitHub:
• Pin 3–6 repos that best reflect your skills
• Keep READMEs sharp and clean
• Avoid noisy commit histories on weak toy projects

These platforms aren’t just your résumé—they’re your billboard.

⸻

🔍 Be Searchable, and Make It Easy to Connect

Use your full name consistently across platforms (or your brand handle). Make sure people can find you by name, GitHub handle, or blog title.

Add contact forms. Post a professional email. Link to your site in your GitHub bio. Make it easy for someone to reach out after they see your work.

⸻

💥 The X-Factor: Authenticity

The strongest brands aren’t fake. They’re focused. You don’t need to pretend to be a 10x genius or tweet in memes. You just need to show up consistently, share your work, and make your value obvious.

Let people see:
• What you care about
• What problems you solve well
• Why you’re worth working with

⸻

🚀 Final Thought

Your brand is already forming, whether you’re shaping it or not. Every project you ship, every post you write, and every way you show up online adds to that signal.

The question is—are you curating it? Or leaving it to chance?

If you want to stand out as a developer, don’t just write good code.

Sell it. Shape it. Share it.

That’s your personal brand.

One Way Binding in Blazor Components

Grant Watson — Sun, 25 Jul 2021 03:36:49 +0000

ORIGINAL POST

Blazor Components: One Way Data Binding

One of the major roles of a developer is on how they can make a static page either in a desktop, mobile or web application dynamic, or even if it needs to be. Binding data is a fundamental task in any single page applications (SPAs). At some point every application needs to either display data in form of labels, or receive data in the form of input fields and select boxes.

While most SPA frameworks have similar concepts for data binding, either one way binding or two way binding, the way they work and are implemented varies widely. In this post, we're going to have a good look at how one way and two way binding work in Blazor.

One Way Binding

One way bindings have a unidirectional flow, meaning that updates to the value only flow one way. A couple of examples of one way binding are rendering a label dynamically or dynamically outputting a CSS class name in markup.

One way bindings can be constant and not change, but often the value will have a reason to be updated. Otherwise it would probably be better to avoid using a bound value altogether and just type the value out directly.

In Blazor, when modifying a one way binding the application is going to be responsible for making the change. This could be in response to user action or event such as a button click. The point being, that the user will never be able to modify the value directly, hence one way binding.

Now that we have a rudimentary idea of what one way binding is, let’s take a look of it in the form of code:

<h1>@Title</h1>

@code {
    private string Title { get; set; } = "Banging Title Mate!";
}

In the code above, we have a component which displays a heading. The contents of that heading, Title, is a one way bound value. In order to bind one way values we use the @ symbol followed by the property, the field or even the method we want to bind too.

<h1>@Title</h1>

<button @onclick="UpdateTitle">Click to Update Title</button>

@code {
    private string Title { get; set; } = "Hello, World!";

    private void UpdateTitle()
    {
        Title = "Greeting, Blazor Friends!";
    }
}

In the first example the value is set and never changed, in this example we've added a method which updates the value of Title when the button is clicked.

As we talked about previously, values can only be updated in one direction and here we can see that in action. When the buttons onclick event is triggered the UpdateTitle method is called and Title property is updated to the new value. Executing event handlers in Blazor triggers a re-render which updates the UI.

One Way Binding Between Components

In the previous examples, we looked at one way binding inside of a component. But what if we want one way binding across components? Using our previous example, say we wanted to display the title of a parent component in a child component, how could we achieve this? By using component parameters.

<!-- Parent Component -->

<h1>@Title</h1>

<button @onclick="UpdateTitle">Update Title</button>

<ChildComponent ParentsTitle="Title" />

@code {
    private string Title { get; set; } = "Hello, World!";

    private void UpdateTitle()
    {
        Title = "Hello, Blazor!";
    }
}

<!-- Child Component -->

<h2>Parent Title is: @ParentsTitle</h2>

@code {
    [Parameter] public string ParentsTitle { get; set; }
}

In the example, the parent component is passing its title into the child component via the child components ParentsTitle component parameter. When then components are first rendered the headings will be the following.

<!-- Parent Component -->
<h1>Hello, World!</h1>

<!-- Child Component -->
<h2>Parent Title is: Hello, World!</h2>

When the Update Title button is pressed then the output will become the following.

<!-- Parent Component -->
<h1>Hello, Blazor!</h1>

<!-- Child Component -->
<h2>Parent Title is: Hello, Blazor!</h2>

Similar to what happened with the earlier example inside a single component. The button click event calls the UpdateTitle method and the Title property is updated. Then the running of the event handler triggers a re-render of the parent component.

This also updates the Title parameter passed to the child component. Updating the component parameter triggers a re-render of the child component, updating its UI with the new title.

I cannot wait to start working on the next post for 2 way binding. If you would like to have me as your personal coach for learning how to program, feel free to email me here or email me directly at info@grantwatson.dev

Blazor Components

Grant Watson — Tue, 20 Jul 2021 21:22:47 +0000

ORIGINAL POST

Blazor Components Basics and Simple Structure:

What are Blazor components?

A Blazor component is an independent part of the Blazor Application. These entities can be as simple or as complex as the application calls for. Blazor applications are made utilizing parts that are adaptable, lightweight, and can be settled, reused, and shared between ventures. A component is the base component of the Blazor application, i.e., each page is considered as a segment in Blazor.

It utilizes the mix of Razor, HTML, and C# code as a part. For example:

@page "/counter"

<h1>Counter</h1>

<p>Current count: @currentCount</p>

<button class="btn btn-primary" onclick="@IncrementCount">Click me</button>

@functions {
    int currentCount = 0;

    void IncrementCount()
    {
        currentCount++;
    }
}

Blazor segments are executed in *.cshtml records utilizing a mix of C# and HTML markup. The UI for a segment is characterized utilizing HTML while dynamic delivering rationale like circles, conditionals, articulations are included utilizing an installed C# language structure called Razor.

In the work square, we can characterize all the properties that are utilized in see markup, and the techniques are bound with control as an occasion.

At the point when a Blazor application is assembled, the HTML markup and C# delivering rationale are changed over into a part class, and the name of the produced class coordinates the name of the record.

Component Members

Individuals from the segment class are characterized in a @functions square, and you can utilize more than one @functions obstruct in a part. In the @functions square, segment states, for example, properties and fields are determined alongside strategies for occasion taking care of or for characterizing other part rationales. Segment individuals would then be able to be utilized as a major aspect of the part's delivering rationale utilizing C# articulations that start with @.

All rendered Blazor views descend from the ComponentBase class, this includes Layouts, Pages, and also Components.

A Blazor page is essentially a component with a @page directive that specifies the URL the browser must navigate to in order for it to be rendered. In fact, if we compare the generated code for a component and a page there is very little difference. The following generated source code can be found in Counter.razor.g.cs in the folder obj\Debug\netcoreapp3.0\Razor\Pages.

namespace SomeBlazorApp.Client.Pages
{
    [Microsoft.AspNetCore.Components.LayoutAttribute(typeof(MainLayout))]
    [Microsoft.AspNetCore.Components.RouteAttribute("/counter")]
    public class Counter : Microsoft.AspNetCore.Components.ComponentBase
    {
        protected override void BuildRenderTree(Microsoft.AspNetCore.Components.RenderTree.RenderTreeBuilder builder)
        {
            // Code omitted for simplicity
        }
    private int counter = 42;
    private void IncrementCounter()
    {
        counter++;
    }
  }
}

[Microsoft.AspNetCore.Components.RouteAttribute("/counter")] identifies the URL for the page.

[Microsoft.AspNetCore.Components.LayoutAttribute(typeof(MainLayout))] identifies which layout to use.

In fact, because pages are merely components decorated with additional attributes, if you alter the Pages/Index.razor file of a default Blazor app, it is possible to embed the Counter page as a component.

@page "/"
<h1>Hello, world!</h1>
Welcome to your new app.
<Counter/>

When embedding a page within another page, Blazor treats it as a component. The LayoutAttribute on the embedded page is ignored because Blazor already has an explicit container – the parent component that contains it.

Creating Components

Depending on your hosting service, and whether you chose Blazor WebAssembly or Blazor Server, the following may be ambiguous. But let’s say for simplicity sake, your main solution has 3 projects: Client/Server/Shared.

Under the Client Project:

Make a new folder called Components. This name can be anything that you wish it to be, for it is not a special or “needed” name. Once you have create the folder, create a file within the folder and name it ComponentOne.razor and the following markup is the starting point of any new component:

//Section 1
@page "/"

//Section 2
<h1>
  Hello World!
</h1>

<p>
  Welcome to your component
</p>

//Section 3
@code {
    //empty code block
}

Let’s stop for a quick moment to discuss what each section is. If you have ever worked in ReactJS or Angular, this may look familiar to you, and feel free to go forward. If this is your first time working in a front end framework, let’s go over some basics:

Section 1:
For clarity and simplicity over the structure/architecture of a component, this is where you will post and dictate your using statements for your components. There is a _Import.razor file to where you can place your using statements, but this is beyond the scope of this article. When you need to declare another file from your solution into you component, put them at the top of your component here. This is also where you can call your Nuget packages you specifically want to use in your component.

The next area you see here is the @page “/”

Similar with routing in React, we dictate the routing of this particular component as “/”. Again, routing is outside the scope of this article, I will have another article covering this in the future.

Section 2:
This area should look “easy” to you. Especially if your component is a simple display component. This area is where you place your HTML code inside the component.

Section 3:
This area is the fun part of the component in my opinion. This is where we combine C# syntax into the component itself. May it be service calls, httpClient and JSON calls to APIs. In this code block, you as the developer can make you component perform magic here.

In the next few articles, I will go into more in the depth and breadth of components, and the following is what I am considering covering:

One Way Binding in Components
Two Way Binding in Components
Component Literals, Expressions, and Directives
Browser DOM and Component Events
Cascading Values
Code Generated HTML Attributes
Capturing Unexpected Parameters
Replacing Attributes on child components
Component Lifecycles
Multi-threaded rendering

If there is a topic that you would like for me to cover with Blazor, or any language that you would like to see, please feel free to contact me through email at info@grantwatson.dev or on Twitter @granticusdev

Programming Languages That Will Dominate

Grant Watson — Mon, 29 Mar 2021 01:31:36 +0000

Original Post

Forecasting the world’s most popular programming languages over the next few years is a difficult task. Oftentimes, bold predictions about a language’s dominance won’t pan out; then you have the languages that seem to come out of nowhere to seize a significant niche (often with a bit of a boost from a major tech company).

Every so often, though, a language’s spike in popularity makes it easier to predict its rosy future. It’s all about the long term—and you should structure your learning (and mastery) appropriately. “I’d recommend deciding what’s important and building your working culture around it rather than worrying about whether you’re missing out by not using a new language,” he adds. “If you’re an individual engineer and want to know how you can help yourself, double down on the fundamentals of how the languages you currently work in interact with the underlying operating system or runtime. A little focus on the fundamentals goes a long way here, and the fundamentals will still be the same in 2030.”

So which programming languages will continue to dominate in 2021?

Python

Artur Yolchan, Senior Software Engineer and owner of the website Coding Skills, says: “Python will probably be the most favorite programming language for developers in 2021.”

The increased use of Python in a specialized context has a lot to do with that, suggests Alex Yelenevych, CMO of CodeGym: “In the development of artificial intelligence systems, Python has proven itself. In addition, many modern and safe sites are written in Python, and it is also very often learned in schools. The language is pleasant and quite simple for beginners, so its popularity will only grow.”

It takes a lot to erode the usage of older, more generalist programming languages, even when newer languages begin to attract a lot of buzz, adds Matt Pillar, VP of Engineering at OneSignal: “Python is an old favorite, and it’s not going away anytime soon. While incumbents like Rust and TypeScript are occupying more and more mindshare, taking some attention away from Python, Python continues to be one of the most loved and most utilized programming languages. With its strong connection to data science toolkits, Python is being taught at an increasing number of programming bootcamps and is well poised to be a favorite first language for developers in the years to come.”

If you’re totally new to Python, start your learning journey by heading over to Python.org, which offers a handy beginner’s guide. Microsoft has a video series, “Python for Beginners,” with dozens of short, Python-related lessons. There’s also a variety of Python tutorials and books (some of which will cost a monthly fee) that will teach you the nuances of the programming language (and don’t forget your IDEs).

JavaScript

Michael O’Connell, Chief Analytics Officer at TIBCO Software, doesn’t think the ultra-popular JavaScript is going anywhere, especially when it comes to dominating developers’ mindshare in 2021:

The maturation of JavaScript as a design and development environment has been phenomenal and will accelerate in 2021. Whether you are working on the front-end with JavaScript, apps and frameworks with React, Angular and vue.js, desktop apps with Electron.js, or backend with Node.js, JavaScript is the ticket! You can even develop machine learning with Tensorflow.js.

I see the worlds of self-service BI and visual analytics becoming ever more mashed up in 2021 with (a) BI and analytics vendors providing seamless experiences for extending their graphics palettes as simple-to-modify native capabilities and deployment; and (b) marketplaces for sharing extensions across broad communities of practice. The maturation of Vega (from the d3 pioneers) as a visualization grammar and platform will help standardize and enforce best practices across these communities.

Yelenevych agrees, citing JavaScript’s frameworks as a key component to its success. “JavaScript—you can find this language in use on almost every website. I think React, already the most popular JS frontend library, will continue to gain popularity. In general, developers love to create applications in React.”

Indeed, it seems virtually certain that JavaScript will continue to serve as the engine that powers the web well beyond 2021, especially as new generations of students utilize it for websites’ scripted behavior. Millions of websites will still rely on third-party JavaScript libraries and frameworks.

Blazor

With the popularity of C#, I believe deeply that Blazor will become extremely popular this year. Typically speaking, programmers love working in one language, especially if that particular language is used for web development. In previous years, for any form of web development, a developer needed at least 2 different languages, a backend API as well as JavaScript/TypeScript. With Blazor now, you can potentially dismantle all use of JS for the use of C# from the backend to the frontend. They utilized the Razor language and WebAssembly, as well as a server side rendering. To read more, see a few of my previous articles listed below:

Why are code reviews important?

Grant Watson — Mon, 15 Feb 2021 19:39:11 +0000

Original post here

Define what a code review is:

Code review is a software quality assurance activity in which one or several people check a program mainly by viewing and reading parts of its source code, and they do so after implementation or as an interruption of implementation.

Git Push & Merge Conflicts Galore

Ideas of why it is a good idea to perform code reviews:

Sharing of knowledge and new techniques
Maintainability
Compliance in quality and requirements
Committers are motivated to write clean code, minimizing mistakes
Sharing of knowledge and new techniques

Every project has a host of unwritten rules and tacit understandings. This "institutional knowledge" must be transmitted to all new arrivals on a project. By definition it is impossible (and perhaps not even cost effective) to write down this information or to convey it all in one sitting. The inductee must acquire this information in the first months on the project, usually elicited from experienced developers when he does something wrong.

Code review can facilitate the communication of institutional knowledge as it relates to code written by the newbie. Experienced team members have the opportunity to impart their wisdom and advice.

At the heart of all agile teams is unbeatable flexibility: an ability to take work off the backlog and begin execution by all team members. As a result, teams are better able to swarm around new work because no one is the "critical path." Full stack engineers can tackle front-end work as well as server-side work.

Ensuring maintainability

The expense of developing software is not just in its initial creation but in the ability of developers to use and modify existing code in the future. Software is notoriously difficult and expensive to maintain. This is especially true when a developer leaves a project and a new developer arrives, but it is even true with a single developer looking back on code he wrote six months ago.

Maintainability is generally achieved by code organization and adequate comments. A person uninvolved in the project should be able to read a portion of code and understand what it does, see the constraints and preconditions of its use and contextual information (e.g. the author used a peculiar technique because of a bug in the OS). In addition, software organizations often have coding guidelines ranging from whitespace conventions to the maximum size of a function. A reviewer can provide the ignorance and objectivity necessary to ensure these goals.

Shell Research saved an average of 30 hours of maintenance work for every hour invested in inspections.

— Software Practice and Experience, 22(2):173-182, Feb. 1992.

It dramatically improves code quality

Let’s make something clear: this is not about standards and code linting (at least not exclusively). It’s about making code more efficient. In a team where everybody has their own background and strong suits, asking for improvements (because that’s what it’s about) is always a good idea. Someone could suggest a smarter solution, a more appropriate design pattern, a way to reduce complexity or to improve performance.

Minimizing your mistakes and their impact

This might seem like the most obvious advantage to the code peer review process, but it’s also one of the most important. When you’re working with the real pressures of time and budget, it’s easy to skip this step. Sure, you’re confident in your work, but even the best coders can go crossed-eyed from looking at their own work too long. Code review helps give a fresh set of eyes to identify bugs and simple coding errors before your product gets to the next step, making the process for getting the software to the customer more efficient.

Simply reviewing someone’s code and identifying errors is great. However, when it comes to the code peer review process there also needs to be a level of follow-up and accountability. Make sure there is process in place for checking back in to confirm code discrepancies have been addressed before moving into production.

Ensuring project quality and meeting requirements

The scope of any given software project and its requirements might run through the hands of several developers. The code review process can serve as a check and balance against different interpretations of that scope and requirements compared to the code that ends up being delivered. The second set of eyes can ensure you don’t fall into the “pit” you created based on your own understanding of what is being asked and that something important hasn’t been overlooked. Having code scrutinized by your peers can save a lot of time “confronting” QA later on.

Improving code performance

Due to the lack of experience, some younger developers might be unaware of optimization techniques that could be applied on their code. The code review process provides an opportunity for these developers to acquire skills and boost the performance of their code. Additionally, it gives these younger developers a chance to hone their skills and become experts in their craft.

While realizing the required functionalities, many developers also try to pursue optimized code for conciseness and performance efficiency. However, this will result in more code complexity and less readability. (Note: Code conciseness doesn’t mean its logic is simple to understand.) Moreover, the data model that the code is built on might change in later development phases. Thus, such premature optimization will eventually increase the cost of maintenance.