DEV Community: Pavneet Singh Saund

Build dynamic breadcrumb routes and child routes with matchPath in React Router v6

Pavneet Singh Saund — Sun, 27 Feb 2022 00:19:36 +0000

When faced with a challenge of implementing breadcrumbs for a business critical application recently I went down a rabbit hole of trying to understand the semantics of react-router and finding a good way of building a dynamic breadcrumb component that didn't break every time a route was added or changed. Let alone need to implement a custom route for every new page. In this post I go into what I ended up with as a routing model that supports dynamic breadcrumbs

The requirements

Maintain a single routing model (or composition of models) as the source of truth for the app
Not have to manually maintain breadcrumbs for different pages
Support child routes
Use the same model to generate bread crumbs for the currently active page.
Be able to show dynamic breadcrumb titles based on parameters.
Bonus: Support generating Navlinks

TLDR;

You can check out this github repository to see my trail and error: https://github.com/pavsaund/react-routing-model/

You can view the code in action on stackblitz: https://stackblitz.com/github/pavsaund/react-routing-model/

Digging into details

It took me a while to really grok the routing model with nested routes in React Router v6. I put this down to coming from very basic use of v5 and mostly using other frameworks. I found this article on nested routes most useful https://ui.dev/react-router-nested-routes. Based on this I realized I wanted to define my routes as a single model, where possible and to use the <Outlet /> component to render the routes for a given path. More info on the usage of <Outlet />.

Let's start with what the routes look like from a React Router perspective, and what you'll likely see in your regular react app.

  <Routes>
    <Route path="/" element={<Page title="home" />} />
    <Route path="/away" element={<Page title="away" />} />
    <Route path="/sub" element={<Page title="sub" withOutlet />}>
      <Route path="zero" element={<Page title="sub-zero" />} />
    </Route>
  </Routes>

I started with the model I wanted, which was built separately from React Router's. The idea is that a simple model can easily be parsed and mapped into something React Router could understand. I didn't want to implement ALL the features of React Router, but just enough for my use case. This worked fine for the initial proof of concept. Then after experimenting a bit and also understanding more of the route model that React Router expected I actually ended up augmenting the RouteObject model with custom properties. This is the end result.

  export interface RoutePathDefinition extends RouteObject {
    title: string;
    nav?: boolean;
    children?: RoutePathDefinition[];
    path: string;
  };

  const routes: RoutePathDefinition[] = [
    {
      title: "Home", path: "/", element: <Page title="home" />,
    },
    {
      title: "Away", path: "/away", element: <Page title="away" />,
    },
    {
      title: "Sub",
      path: "/sub",
      element: <Page title="sub" withOutlet />,
      children: [
        {
          title: "Sub-Zero", path: "zero", element: <Page title="sub-zero" />,
        },
      ],
    }
  ];

The <Page />-component is a simple helper component to render a page with a title, and the withOutlet prop is an indication to render a <Outlet /> component for the child routes to render. Implementation here.

Building the breadcrumbs

Now, for the fun part - actually understanding how to get the active path from React Router. This is where grokking how React Router builds its paths were important. I realised after hitting my head on the wall that there is no central place where all the routes are stored that is exposed through public API. (There is an exposed UNSAFE_RouteContext if you want to live on the edge). My current understanding is that React Router and nested routes seem to work by each level of the router owning its own routes and the next level to take over. Meaning that a parent route doesn't actually know anything about its children, and a child only knows its own path pattern based on the resolved parent's route. Now to build the breadcrumb.

Matching the top-level crumb with `matchPath`

Using the matchPath utility the React Router will match the given location against the path provided. It also returns the resolved pathname, and any params it resolves. By specifying end = false; on the PathPattern option will allow a partial match on the supplied location. This allows us to know if a given pattern is part of the current location, and should be included in the breadcrumb or not.

So, let's resolve the top-level paths aginst to our second route /sub/zero

const location = useLocation(); //for '/sub/zero'
matchPath({path: '/', end: false, },location.pathname); // returns match
matchPath({path: '/away', end: false, },location.pathname); // returns null
matchPath({path: '/sub', end: false, },location.pathname); // returns match

Great, so this means that both the Home and Sub paths match and can be added to our breadcrumb. Like so:

function matchRouteDefinitions(
  definitions: RoutePathDefinition[],
  locationPathname: string
): PathMatch[] {
  const crumbs: PathMatch[] = [];

  definitions.forEach((definition, index) => {
    const match = matchPath(
      { path: definition.path, end: false },
      location.pathname
    );
    if (match) {
      crumbs.push(match);
    }
  });

  return crumbs;
}

const matches = matchRouteDefinitions(routes, '/sub/zero');
/** simplified matches
 * [
 *  {pattern: '/'},
 *  {pattern: '/sub'}
 * ]
 * /

Matching children

So, now how can we match the zero child route? Let's manually match again

const location = useLocation(); //for '/sub/zero'
matchPath({path: 'zero', end: false, },location.pathname); // returns null
matchPath({path: '/sub/zero', end: false, },location.pathname); // returns match

OK! Now we're getting somewhere. It's not enough to match against the path pattern itself, you also need to match with the parent pathname. So let's add the parent path into the mix.

function joinPaths(paths: string[]): string {
  return paths.join("/").replace(/\/\/+/g, "/");
}

function matchRouteDefinitions(
  definitions: RoutePathDefinition[],
  locationPathname: string,
  parentPath: string = ''
): PathMatch[] {
  const crumbs: PathMatch[] = [];
  const pathPatternWithParent = joinPaths([parentPath, definition.path]);

  definitions.forEach((definition, index) => {
    const match = matchPath(
      { path: pathPatternWithParent, end: false },
      location.pathname
    );
    if (match) {
      crumbs.push(match);

      if (definition.children) {
        const nestedMatches = matchRouteDefinitions(
          definition.children,
          locationPathname,
          pathPatternWithParent
        );

        crumbs.push(...nestedMatches);
      }
    }
  });

  return crumbs;
}

const matches = matchRouteDefinitions(routes, '/sub/zero');
/** simplified matches
 * [
 *  {pattern: '/'},
 *  {pattern: '/sub'}
 *  {pattern: '/sub/zero'}
 * ]
 * /

There's a bit more going on here so let's break down what's happening.
parentPath has been added as a parameter with a default value of ''. Then using the joinPaths function the parent and definition path are joined, and any redundant // are replaced with a single slash.

Next, if there are children on the matched route, then recursively call the matchRouteDefinitions with the child routes. This time we pass in the pathPatternWithParent as the parentPath parameter, which then allows the child router paths to match.

Now, this is the happy path (pun intended 😏) implementation. There are some edge cases you may or may not want to support.

Edge case 1: Don't match breadcrumb for `/` - Home route

For my use case, I didn't want Home to show up, so I added another path check before deciding to add the path match

 //...
   definitions.forEach((definition, index) => {
    //...
    if (match && definition.path != '/') {
      crumbs.push(match);
    }
    //...
  });

  const matches = matchRouteDefinitions(routes, '/sub/zero');
  /** simplified matches
   * [
   *  {pattern: '/sub'}
   *  {pattern: '/sub/zero'}
   * ]
   * /

Edge case 2: Don't match a no-match/catch-all route

It's common to add a NoMatch route to serve a user with a 404 page of some kind. The problem is that this route will match anything - which is kind of the point.

  routes.push({
    title: "404", path: "*", element: <Page title="404 Not Found" />,
  });
  const matches = matchRouteDefinitions(routes, '/sub/zero');
  /** simplified matches
   * [
   *  {pattern: '/'},
   *  {pattern: '/sub'},
   *  {pattern: '/sub/zero'},
   *  {pattern: '*'},
   * ]
   * /

So, we can add the * pattern to the ignore list as well.

  const skipPaths = ['/', '*'];
 //...
   definitions.forEach((definition, index) => {
    //...
    if (match && !ignoredPaths.includes(definition.path) {
      crumbs.push(match);
    }
    //...
  });

  const matches = matchRouteDefinitions(routes, '/sub/zero');
  /** simplified matches
   * [
   *  {pattern: '/sub'}
   *  {pattern: '/sub/zero'}
   * ]
   * /

Edge case 3 - Child route with ''-path with redirect matches parent route

For a use case where a child route has an empty path then the resolved from matchPath ends up being the same. This may actually be what React Router refers to as an Index path - but I haven't explored that aspect enough yet.

 routes.push({
    title: "Another",
    path: "/another",
    element: <Page title="Another" />,
    children: [
      { title: "Another-index", path: "", element: <Page title='Empty' />}
      { title: "Another-other", path: "other", element: <Page title='Other' />}
    ]
  });

  const matches = matchRouteDefinitions(routes, '/another/');
  /** simplified matches
   * [
   *  {pattern: '/'},
   *  {pattern: '/another'},
   *  {pattern: '/another'},
   * ]
   * /

This means you need a guard or check in place before adding the match.

function getPreviousMatch(previousMatches: PathMatch[]): PathMatch | undefined {
  return previousMatches[previousMatches.length - 1];
}

function isNotSameAsPreviousMatch(previousMatches: PathMatch[], match: PathMatch): boolean {
  const previousMatchedPathname = getPreviousMatch(previousMatches)?.pattern ?? "";
  return previousMatchedPathname !== match.pattern;
}

function isMoreSpecificThanPreviousMatch(previousMatches: PathMatch[], toPathname: string): boolean {
  const previousMatchedPathname = getPreviousMatch(previousMatches)?.pathname ?? "";
  return toPathname.length > previousMatchedPathname.length;
}

function canBeAddedToMatch(matches: PathMatch[], match: PathMatch) {
  return (
    isNotSameAsPreviousMatch(matches, match) &&
    isMoreSpecificThanPreviousMatch(matches, match.pathname)
  );
}

 //...
   definitions.forEach((definition) => {
    //...
    if (
      match &&
      !ignoredPaths.includes(definition.path &&
      canBeAddedToMatch(matches, match)
    ) {
      crumbs.push(match);
      if (definition.children) {
        //...
        nestedMatches.forEach((nestedMatch) => {
          if(canBeAddedToMatch(matches, nestedMatch)) {
            crumbs.push(nestedMatch);
          }
        });
      }
    }
    //...
  });

  const matches = matchRouteDefinitions(routes, '/another/');
  /** simplified matches
   * [
   *  {pattern: '/'},
   *  {pattern: '/another'},
   * ]
   * /

Rendering routes

So, now that we have all our routes defined in a nice object, wouldn't it be good to render them using that same object? As I mentioned in the introduction, this caused me some pain until I realised I could extend the RouteObject that React Router already exposes. Then it's possible to use the useRoutes hook to do the rendering for you.

import { routes } from './routes';

export default function App(){
  const routesToRender = useRoutes(routes);
  return (
    <div>
      <h1>My App</h1>
      {routesToRender}
    </div>
    )
}

Then in the page that has child routes, including the <Outlet /> component. Remember to do this for each component that has child routes. React Router will then figure out which child routes to render there.

import { Outlet } from "react-router-dom";

export default function Sub() {
  const routesToRender = useRoutes(routes);
  return (
    <div>
      <h1>Sub</h1>
      <Outlet />
    </div>
    )
}

Rendering the breadcrumbs

Now that we have all the moving parts in place, we can put it all together in the Breadcrumbs component. In the below exampled the matchRouteDefinitions function now returns an ActiveRoutePath which is a structure that includes both the match and the RoutePathDefinition for convenience.

export type ActiveRoutePath = {
  title: string;
  match: PathMatch<string>
  definition: RoutePathDefinition;
};

function useActiveRoutePaths(routes: RoutePathDefinition[]): ActiveRoutePath[] {
  const location = useLocation();
  const activeRoutePaths: ActiveRoutePath[] = matchRouteDefinitions(routes, location.pathname);
  return activeRoutePaths;
}

export function Breadcrumbs({ routes }: BreadcrumbsProps) {
  const activeRoutePaths: ActiveRoutePath[] = useActiveRoutePaths(routes);
  return (
    <>
      {activeRoutePaths.map((active, index, { length }) => (
        <span key={index}>
          {index === 0 ? "" : " > "}
          {index !== length - 1 ? (
            <Link to={active.match.pathname}>{active.title}</Link>
          ) : (
            <>{active.title}</>
          )}
        </span>
      ))}
    </>
  );

Now, in our App.tsx we can include the breadcrumbs path and it will render breadcrumbs automatically based on the page you are visiting.

export default function App(){
  const routesToRender = useRoutes(routes);
  return (
    <div>
      <div><Breadcrumbs routes={routes} /></div>
      <h1>My App</h1>
      {routesToRender}
    </div>
    )
}

Conclusion

In conclusion, matchPath can be used to manually match a path pattern against the current url to build breadcrumbs for the routes along the path. As a bonus, by extending the RouteObject type exposed from React Router 6, you can add capabilities specific to your application's needs.

There are two requirements I haven't dug into yet in this post. Stay tuned for the follow-up posts that will cover these cases:

Be able to show dynamic breadcrumb titles based on parameters.
Bonus: Support generating Navlinks

I hope you enjoyed this post. Let me know if it's been useful to you, or if you have feedback.

Highlights from the Aurelia vNext 2019 fall update

Pavneet Singh Saund — Sat, 02 Nov 2019 21:09:31 +0000

There was a recent blog post with the status of Aurelia vNext. For those of you that don't know, Aurelia is a front-end framework with a focus on standards, extensibility, ease of use and performance. It's been a while since a new major release, so vNext is a pretty big deal.

These are some highlights of what I found pretty cool in the latest update:

Official name: Aurelia 2
VSCode integration with direct linking between bindables, observables, views, and custom attributes to their backing code representation
VanillaJS-like performance with JIT (Just in time) optimisations, and new AOT (Ahead of Time) optimisations
Extensibility that allows you to emulate the syntax of other frameworks, like Angular / Vue etc
A continuous focus on Web Standards
Developer Experience has received som pretty considerable features, here are the ones I'm excited about
- More lifecycle hooks, and they are now synchronous. (no more queueMicroTask!)
- New Router 🙌
- Functional API's
Multiple Integration scenarios that allow nesting of frameworks, and connecting other libraries directly in the underlying pipeline and more
Extensive Test Tooling support, helpers and libraries.

The team is focused on keeping the migration path straight forward, though they have mentioned there'll be a few breaking changes.

A lot of these improvements are raising the bar so high that we're bound to see more developers discover the joys of using Aurelia, as well as making that transition a lot easier for them with extensibility points.

I'm pretty excited about the future of Aurelia 2, but doubt I'll be getting my hands dirty just yet. Looking forward to a preview/release candidate before I start testing it out, and more of the WIP features are in place.

Adding a /now page

Pavneet Singh Saund — Thu, 03 Oct 2019 18:50:37 +0000

TL;DR: I’ve written and published a /now page.

For more of the back story and understanding what it is, read on.

I can’t remember when I first stumbled over Derek Sivers. It could have been one of his posts on giving away all his money, or perhaps his TED talk on leadership lessons from a dancing guy. Regardless, at one point in time I remember reading about the concept of a now page. I found it intriguing, but never really got around to it.

What is a Now Page?

The concept is quite straight forward. It’s not an “about page”, nor is it a “contact page”. It’s a page describing what’s going on in your life right now.

Think of what you’d tell a friend you hadn’t seen in a year.

But why even have a Now page?

This sums it up well:

It’s useful for the same reason an “about” page is useful on your site: because people on your site want to know more about you.

Besides answering the common question, “What are you up to these days?”, those who have a now page say it’s a good reminder of their priorities. By publicly showing what you are focused on now, it helps you say no to other requests.

The time is Now

For some reason, the story of the first follower has stuck with me. It’s powerful when another person echoes your voice, or if you choose to echo another’s. It seems the effects of being that first follower can have long-tail impact. I realised while re-reading Derek’s original now-post that his first follower was Gregory Brown, a person who has been influential on my journey.

It’s taken me a few years, but the time has finally come to put up my Now-page. Perhaps a little too much overlap to an about page — but I suppose it will evolve.

To get more info about Now-pages, check out: nownownow.com/about. Also, check out my profile on nownownow.com

Originally published at https://pavsaund.com on October 3, 2019.

Does Aurelia Support React-like Hooks?

Pavneet Singh Saund — Tue, 01 Oct 2019 20:58:11 +0000

There was recently a post on the Aurelia Discourse that caught my attention asking how react-like hooks would work when using Aureliajs. The response from Aurelia’s creator underlined some of the reasons why I trust Aurelia to build JavaScript applications with Aurelia.

Rob raised three aspects that Aurelia had that alleviated the need for “hooks”

With Aurelia, we don’t need hooks because we have three very powerful things:

Observability

Dependency Injection

Metaprogramming

He continues in his post to describe how Aurelia doesn’t try to re-invent the wheel but instead use time-tested OOP-practices that cater to Separation of Concerns.

On Observability:

With Aurelia, we can observe normal objects/class properties. So, you can leverage the last 40ish years of OOP techniques and battle-tested approaches to building software. Also, the general observer pattern has been around for a very long time and has scaled to some of the most complex apps today.

The interesting aspect here is that he explains how the patterns of other frameworks (React / Vue) leverage different techniques, and tools to compensate for their lack of support for full observability. With Vue coming in close to Aurelia, with some edge-cases that are uncovered.

On Dependency Injection:

On the other hand, Aurelia has a very powerful DI framework. This lets you decompose any problem into small pieces that work together to tackle something complex. Need to make something reusblabe? Just factor it out into a new class and inject it wherever you need. That’s a basic form of composition that works very well, with decades of history behind it.

On Metaprogramming:

None of the frameworks have metaprogramming capabilities like Aurelia. In Aurelia’s case, you can apply a decorator to a class, and the framework will use your declaration to “write” code for you, so you don’t have to. We take this further with conventions. So, you can write vanilla js, following a simple pattern, and Aurelia will write code for you to make things into custom elements, etc…

Some reflections

Rob ends the piece by encouraging people to keep up to date on trends & techniques, but not to forget the years of learnings that have gone into existing techniques that work.

I also think it’s important to recognize that there are different kinds of applications where features from React or Vue make more sense to use. Either because of the features those frameworks/libraries have, or because of the community support they have with plugins, libraries and helpers.

Originally posted on the Dolittle Community Forum & published on https://pavsaund.com on October 1, 2019.

Officially backing Aurelia Front-End Framework

Pavneet Singh Saund — Tue, 16 Apr 2019 21:53:55 +0000

Officially backing Aurelia Front-End JavaScript Framework

After discussing our strategy around front-end JavaScript frameworks at Dolittle, we decided to make our framework of choice official by becoming a backer of the open source front-end framework Aurelia!

Open Collective backing badge from Dolittle’s official backer page

Why donate to Open Source?

At Dolittle, we believe in developing our platform in the open, and part of that is leaning on the work of other open source projects. We try to find ways to contribute back to open source and becoming an official backer is something we felt strongly about when it came to Aurelia.

Why Aurelia?

We’ve been using Aurelia as the defacto frontend JavaScript library for building our products, and the default framework for our open-source extensions for a while now.

It’s not the hottest framework out there, nor the framework that has the most likes on GitHub. What it is though is a framework that aligns very well with our development principles for building typical Line-of-Business applications.

It is Built on Open Web Standards, Open Source, Inspired by MVVM, Convention over Configuration, Fully Extensible and Separation of Concerns, to name a few.

It’s also gaining momentum with a committed and active core team who are working towards a vNext release.

In conclusion

We want to thank the Aurelia team and open source contributors for their countless hours of work and hope our contribution helps them reach their goals. As their work is helping us reach ours.

Rob Eisenberg

@eisenbergeffect

Big thanks to @Dolittle for their donation to @AureliaEffect opencollective.com/aurelia 🎉😊

13:57 PM - 16 Apr 2019

217

We also want to take the opportunity to bring focus to this great framework and its helpful community. Do check out Aurelia, if you haven’t done so already.

A note on other frameworks…

We want to make it very clear that our backing of Aurelia doesn’t mean you can’t use other front-end frameworks with Dolittle. We’re happy to say that you’re free to select whichever front-end framework you prefer. We have plans to add official support for more in the future.

Clap 👏 or follow to read more articles on Aurelia, and the open source application platform and company, Dolittle.

Originally posted on the Dolittle blog.

2018 in review

Pavneet Singh Saund — Mon, 14 Jan 2019 22:23:53 +0000

As is the tradition I want to spend a few minutes reflecting on the year 2018. I find that taking time to reflect gives me a perspective of where I am on my journey. Reflecting also helps give closure and allows me to direct my thoughts and efforts towards what I want to accomplish in the future.

2018 has been one of the most exciting years from a professional perspective. From a personal growth perspective, 2018 has been both rewarding and frustrating. How can this be, you may ask (or not)? I’m asking at least and will be exploring that in this post.

Putting things into perspective

Having some perspective on where you are in life brings context. It allows you to understand where you need to focus your efforts and what you can expect from the outcomes. Without perspective, expectations run amok, and this has been a theme of mine for the last year.

Let’s add some perspective by looking at the themes of the past few years:

2015: The year I hit my first real burnout. A low point in life that has turned out to be an eye-opening experience. I also became a dad for the 3rd time.
2016: The rebound year and discovering I had more to offer. My most active blog year, podcast appearance and a conference talk.
2017: Exploring ideas, video, and vulnerability. Putting myself out there on all fronts, blog, vlog, stoicism, and several conference talks.
2018: Change, Challenges, Struggle, Failure, Growth. Let’s dig in!

Change, Challenges, and Struggle

This year brought around a significant change — a shift in careers. I transitioned from a Web Developer / Team Lead with a path towards Agile Coach / Management / Leadership type of roles at a larger company to becoming a founding employee at the startup, Dolittle (more on this some other time).

The role I took, and currently have is User Experience Lead / Web Developer, and as with any (small) company; titles mean nothing. User Experience is a new field for me to dive in to, practice and build skills in. Even though I’ve been a developer for many years, building applications in modern JavaScript has been an exciting challenge.

Days have been filled with more frontend and JavaScript work than any before, both for our products and client projects as well as all the aspects of building a great culture and the fundaments of a company that will last for years to come.

Failure

Working in any startup is hectic, and that’s also what I experienced, even though we limited ourselves to regular workdays, the sheer number of balls we needed to juggle was overwhelming at times. The transition has been exciting, invigorating and also painful. On one side I’ve wanted to explore and establish what UX is at Dolittle, and on the other, coding and working with clients to bring in some income naturally took precedence. All of the while fumbling trying to get on board with modern JavaScript Web Development. This lead to a feeling of not feeling adequate or competent in any of the work I was doing.

Another consequence of feeling like all my energy was going towards not accomplishing things were the negative thoughts and the stories I was telling myself. Luckily for me, the people I decided to work with that Dolittle are some of the best humans I’ve ever had the privilege to know, second only to my life partner, and they offered their support. But the feelings still lingered — this was something I needed to work through and deal with for myself. Which leads to my next real failure — Not taking time to reflect and process how much I was learning.

On a related note, I realise that previous accomplishments have been holding me back from future achievements. I’ve struggled to put my self and content out there for several reasons, one of them has been constantly comparing and raising the bar based on those previous accomplishments, without applying any form of context or perspective. The word “should” has been used way too often, which leads to an internal dialogue of shame.

Growth

Things were looking a lot brighter towards the end of the year. I was more comfortable with the day-to-day challenges we had at work, as well being able to acknowledge my role and the contributions I was making. The brighter outlook gave me some space to reflect on my learnings. I was also able to identify a weakness I had (with help from colleagues), namely that I self-censor myself a lot. This weakness manifested itself in not speaking up in meetings, not sharing my thoughts on what I felt was important through other communication channels, and also it put a solid block over any attempt I made to write anything in public. Holding back thoughts isn’t to be confused with reflecting and pondering over a topic before forming an opinion (which I also do), but when it was evident that I had something to ask or say — I didn’t.

I was afraid. Afraid to not have the right answer, to appear foolish and found it easier to keep thoughts within. Identifying this specific behaviour has been a critical discovery. Being afraid of allowing myself to be imperfect is a root behaviour for quite a lot of the issue I’ve been facing, and is something I’ll be working on in the coming year.

As I mentioned earlier, being in a startup means wearing multiple hats, and this has been the year I re-embraced modern javascript web development with AureliaJS. It’s been a painful process of wanting to deliver and ship great products but stumble on “simple” things like identifying component abstractions, understanding es6 syntax, as well as learn the framework itself. My inner voice talking down these learnings as simple things is another manifestation of the “should”-problem with unrealistic expectations.

When I now look back, I’m proud of the progress I’ve made in this area. From feeling inadequate to be able to write and structure applications, write re-usable and business components, and drive application logic with TDD in less than a year has been a huge win.

None of my learnings would have been possible without the people I’m around me. They say that you are the average of the 5 people closest to you, and I’m surrounded by 5 of the most influential people in my career, not to mention them surrounded by others they are equally influenced by. I’m humbled, honoured and so privileged to be able to work in these conditions.

On a private note

On a private note, I want to mention running. 2018 has been the year I purposefully made running a habit. I have some big hairy goals for 2019 when it comes to running, namely complete a marathon towards the end of the year, which means taking the habit and applying running plans & structure.

I’ve also cut drastically down on phone usage around the family as well. Disabled my facebook account, removed twitter from my phone, and optimised more time to be present with them. It’s come in handy as our 3rd child has made the transition from innocent toddler to chaos monster (3 yrs old).

I’ve also been able to plough through quite a few books during my commutes. For anyone interested, you can see my progress on Goodreads.

In conclusion

Summarising the ups and downs of an entire year in a post is challenging in itself, and writing this has been a lot harder than expected. I knew I wanted to write this before spending time on anything else, so it had the potential to become a blocker for me.

I also wanted this to be a personal reflection post, rather than a set of useful tips, things I’ve learned, quick wins — lists of accomplishments, contributions and side projects. There’s enough of that out there. Instead, I hope this post reminds people that life is messy. We all have our ups and downs, our cycles of growth, expansion, reflection. That doesn’t mean that you’re less than others in any way, just that you’re human and on your own journey.

At the end of the day, I’m privileged to work alongside some fantastic people, on a great mission together, building the company we’ve always wanted to work in. All the while, having a precious family life and being able to spend quality with my kids.

In retrospect, the year 2018 has been precisely what I needed to prepare for me for 2019. That’s how I choose to see it, at least, and perhaps that’s enough?

How has 2018 been for you? How are you doing with the transition to 2019? Please share your thoughts and reflections.

Originally published at codingwithempathy.com on January 14, 2019.

Proof of Concept? MVP? Just tell me when it’s done!

Pavneet Singh Saund — Mon, 26 Nov 2018 10:01:01 +0000

The meeting between iterative product development and a company used to approaching product development through the project-lens can be quite harsh.

On one hand, you have set budgets and revenue targets. The project deliveries have been planned out in detail for the coming months, quarters or even years, with a chain of dependencies for the rest of the year.

On the other hand, you need to follow up deliveries and make day-to-day decisions that affect the scope and the end product drastically in a true agile manner.

All the while nobody can give an answer to whether you’ll hit your targets or not. And you, as a stakeholder or project owner, just want to know when it will be done!

Here’s the deal…

There are a few things to note when moving into this world of digitalising organisations and iterative product development.

Agile™️ doesn’t mean faster or cheaper.
You decide when it’s done.
Product development is hard.

If you’re willing to take my word for it then you can stop reading now. Otherwise, please continue…

Agile / DevOps / Lean doesn’t mean faster, cheaper or easier

Digitisation has been sold into organisations as the “way to go” and alongside this the notion of some form of agile software development. The implication (or outright promise) is that this form of development will be faster, cheaper or both. There are no guarantees of this.

Instead, what these practices mean is that you are able to test your assumptions in a more iterative manner. This means you can create just enough of a product that will allow a customer to use it and give you feedback before your next iteration. So, in this sense, it’s a lot cheaper to verify you are on the right path, and the cost of course-correcting is a lower than if this was a project going over several months or years.

Working this way is more demanding of your time, as you are now part of the team that builds and discovers the product — you need to be available on a more ad-hoc schedule. There are more small follow-up meetings and constant changes to priorities based on customer feedback, or new opportunities. Working like this is engaging and fun, but it can also be draining. Especially if you’re used to the more traditional “ordering” of software through larger “waterfall” -projects.

Product Development is Hard

The hardest part of building a software product is knowing what to build. You may have an idea of what you want to create, but will that actually meet people’s needs? Saying you need an app or a service doesn’t instantly make it something that people want to use. The only way to find the market-fit is to test it out with real customers and users. This is what an iterative development methodology offers — the chance to test assumptions before you run out of budget (money, time, goodwill, etc).

Gone are the days where business and in-house customers accepted sub-par products to be able to get their work done. Consumers are used to sleek, intuitive apps on the web and their devices. There’s no magic switch that causes these same people to lower the bar of what they expect when they enter their work setting.

This expectation of quality becomes a challenge for businesses wanting to raise the bar. As the quality of the products improves, so does the need to build the right thing. It is crucial to verify whether the pain you are trying to address is one the people using your product actually feel, and want dealt with.

To keep up with this pace means focusing more on product development as a core discipline, instead of something to be outsourced or managed from afar.

You decide when it’s done.

The dirty secret is that “it” is never really done — the elusive product remains a moving target. Getting something out the door is just the first step. Instead, the focus should be:

When is the product good enough to be valuable to the people using it?
How much are you willing to spend to find out how close you are to fulfilling those needs?
How do you know the product is actually attending to the needs and delivering value?

With an iterative process, you have the opportunity to approach answering these questions and respond by changing the direction of your product. But the only way I’ve found to get real feedback is to give full slices of functionality in front of real users.

Sketches, prototypes, proofs of concepts and minimum viable products are all viable approaches to elicit feedback — the earlier the better. Pick your flavour, be harsh with the scope, and get a working product out there!

Finally

Organisations’ need for fixed budgets, scopes and roadmaps can hinder you from realising the tantalising promise of value in a truly iterative product development cycle. That value is the agility to be able to respond to changing needs, and new opportunities.

Embrace experimentation through continuous feedback cycles and adjust the reality of where you are with a product based on them. Based on these feedback cycles you’ll know when you’re done.

Clap 👏 or follow Dolittle to read more about how we believe in enabling others to create products that help users feel like superheroes.

Cover Photo byJosé Alejandro Cuffia on Unsplash

This post appeared originally on the Dolittle blog

Hitting refresh

Pavneet Singh Saund — Wed, 16 May 2018 21:46:04 +0000

Unlearning is one of the hardest parts with any transition. You bring with you many years of experiences, expectations and biases. These have built up over time through different work situations you have adapted to. Past experiences allow you to hit the ground running when it comes to work and communication. They can also be heavy baggage, slowing you down. In a startup this baggage could be the very thing that’s holding you back. You’re looking at completely new problems with views that don’t match your situation.

Here at Dolittle, we’re hitting refresh on many of our previous assumptions. Looking at old problems with fresh eyes. How we approach our coding practices. How we are working with customers. How we are approaching contracts. How we are building products. We’re re-learning, and allowing our culture to grow.

“If your mind is empty, it is always ready for anything, it is open to everything. In the beginner’s mind there are many possibilities, but in the expert’s mind there are few. ” -Shunryu Suzuki

An example is communication. Coming from a very distributed team, a few of us wanted a more formal process. More documentation, more written communication. This is important down the line as we grow, but not so much in the beginning when priorities change almost daily.

Hitting refresh is an important part of starting anything new. Making it explicit that you need to take a step back and reconsider your expectations. You’re going to have new problems and you can’t deal with them if your focusing on solving the problems you had in the past. At the same time, it’s importatnt to leverage universal learnings and principles. It’s also important to recognise the context in which those are valid.

Are they really valid to you now?

Photo by rawpixel on Unsplash

This post appeared originally on the Dolittle blog

Tribes — a search for belonging

Pavneet Singh Saund — Tue, 27 Feb 2018 21:41:24 +0000

Finding your tribe isn’t easy. It’s a long journey of many missteps. You may be part of a tribe your entire life. You may wander to look for other tribes out there and dive back into your old tribe for safety. Other times you need to find another to call your own. Sometimes you need to start your own with your closest around you. Other times you need to just start, and hope others will follow.

Tribes

But, what do I mean with a tribe? In this context I’m using it as a community where you feel a sense of belonging. Originally, tribes were defined by proximity, the land you belonged to. So changing tribes was a physical action. Moving from one area to another. Going through rituals and sacrifices to leave your original tribe and be accepted in your new one. It took a lot of friction.

In society today the sense of belonging to a certain part of land isn’t what defines our tribe any longer. We define it in other ways like: race, nationality, gender, faith, community, workplace, hobbies etc. Some are hierarchical, like your team, that resides within your department in your organization and others are virtual, like social media groups, forums, interests, programming languages.

In our digital age there is a lot less friction to switch between tribes. You can find a virtual tribe, where switching could be as simple as joining another group. You can physically move across the world and still stay in the same virtual tribe, even though you may change your physical one.

A sense of belonging

As we grow and mature, we all go through our own versions of “the hero’s journey”. Moving through life, searching for a place of belonging.

My family tribe has always been important to me, it’s the most rock-solid tribe I belong to. Our shared values define the core of my belief and value system, and in extension is the lens I see the world through.

Another tribe that gives me a sense of fulfilment is meaningful work alongside caring individuals. Working to make a change in this world for the better. It’s what’s guided me unconsciously so far, and now what I’m starting to become more aware of and act upon.

The search

It’s become easier than ever to find and change tribes. It’s also easier than ever to get distracted in your search. The best we can do is follow our heart, and not settle. As we grow, so do our needs and finding a tribe that allows you to grow to your full potential is something I think is worth searching for.

As I’ve become more aware of my journey and what is important to me, I’ve also been more aware of what I want from my tribe. I’m sure this will evolve and change as I grow, and I’m sure that no tribe will be a perfect match. I do know that when I see something that is closer to my own values I need to make the move. How else will I know if it’s what I need?

“If you haven’t found it yet, keep looking. Don’t settle. As with all matters of the heart, you’ll know when you find it. And, like any great relationship, it just gets better and better as the years roll on.” ― Steve Jobs

So, if you’ve found your tribe — cherish it, nourish it and consider yourself lucky. If not, work through the friction and don’t settle.

Originally published at codingwithempathy.com on February 27, 2018.

Coding with Empathy in 2017

Pavneet Singh Saund — Sat, 30 Dec 2017 22:02:20 +0000

Empathy — the 4th most popular word in 2017, according to Merriam-Webster. It’s interesting that this word has risen up in its popularity this year. Mirriam-Webster also points out the connection between politics in the USA, and the increase usage and searches for empathy.

Here’s Google’s take on how empathy is doing 2017. This is a trend graph compared to sympathy and compassion:

So, definitely something people are becoming more aware of, and possibly also exploring.

The Blog

This blog hasn’t been as active as in 2016, but there has been some activity.

3 of my most popular blog posts came out this year, and have been well-received both on this blog and on the great dev.to platform.

The PAVLOG

As announced in the 2016 summary, I explored video this year, with a month of daily vlog episodes exploring daily reflections on The Daily Stoic by Ryan Holiday. I was inspired by two of Ryan Holiday’s previous books; The Obstacle is the Way and Ego is the Enemy. These introduced me to Stoicism, and how valuable this philosophy is. The 30 episodes of the Vlog was an eye-opening experience for me, on a personal and professional level. I found new joy in editing videos, learning about stoicism, and combining this with a daily journal that also doubled up as a vlog.

Feel free to check out the results, and let me know what you think:

Conference talks / Podcasts

Empathy was also in focus on the conference scene this year, as I presented at NDC Oslo and QCon New York. Both talks are recorded and are available.

I’m really happy with how these talks turned out, and the feedback from them. Though they are very similar, I think the second iteration at QCon NYC really struck home.

I also had the chance to have a chat with Shawn Hastie for the InfoQ Engineering Culture Podcast where we dove into topics of team leadership and empathy. It was a good chat, and certainly something I’d love to do more of.

#goofyreligion

I can’t have a summary of 2017 without mentioning the #goofyreligion group on twitter. What started out as a joke by Dave Rael quickly escalated to a hash-tag a few of us rallied around to help motivate each other to take care of our health, physical and mental.

The tweet that started it all: // Detect dark theme var iframe = document.getElementById('tweet-898018961798832128-419'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=898018961798832128&theme=dark" }

To learn more about the #goofyreligion and also a great conversation on balance and functional programming check out Reid Evans on the Developer on Fire Podcast

Episode 294 | Reid Evans - Connected Mindset

Developer on Fire

Your browser does not support the audio element.

1x initializing... ×

Gratitude

The second half of 2017 has been about gratitude for me. Not so much about external gratitude, but internal. Appreciating the people around me. Putting them in focus after a lot of focus on myself and my activities. I suppose it’s about balance, really. I spend time doing these things in public to help others, but at the end of the day I also need to be there for the people around me. So a special thank you to my wife, kids and family.

I want to thank the wonderful people at KomplettDev. It’s a joy to work with so many individuals bringing their whole selves to work every day and building the best web-shops in Europe.

I also want to thank the #goofyreligion gang (with friends). These people inspire with their actions, and their words. I’m lucky to have you, and looking forward to sharing the #goofyreligion with more people in 2018.

A special thank you to Emil Cardell for giving me a journal and pen after the NDC Oslo talk. I now journal every day and am better for it! 150 days of journaling so far this year.

Looking Forward

I’m striving for balance, and finding a healthy way to push myself on all fronts. I’ve discovered this means tackling some bad habits I’ve built up through my life and understanding that changing my mindset is going to be hard. A keyword here is rewiring habits.

There are also some new things happening, which have me really excited and I hope to share more of that in 2018!

Finally I’d like to thank each and every one of you readers for putting empathy in your lives, and for those around you. I’ve seen a lot of positivity in our communities that give me a lot of hope of bringing safety into our profession. But there’s a long way to go yet. So, let’s continue our work in 2018.

Originally published at codingwithempathy.com on December 30, 2017.

Controlling the source of truth - The value of better commit messages

Pavneet Singh Saund — Mon, 08 May 2017 20:42:17 +0000

Post originally published on codingwithempathy.com

Working as a developer involves communication on many levels. We need to communicateÂ withÂ business stakeholders in a domain specific language, abstracting away much of the technical jargon. Team communicationÂ on the other hand is a lot more technical, and closer to our reality in code.

AÂ lot of our communication is silent though. It happens through async tools like email, Skype or Slack. I'm sure that anyone that's attempted communicating this way has experienced how easy it is to under-communicate, leading to a ping-pong of messages before the intent and understanding is conveyed.

The end goal of all this communication is software that delivers value to users.

Software isn't finished when it's been delivered. It changes over time and loses its original intent. This leads to even more async communication, which can go over months or years. I'm talking about the communication that happens through the code we write.

Breaking down communication in code

What -Â All written code explains what it does. Functionally correct code that executes the right end-result through a compiler.

How -Â Some explains how it's done. Code has to be readable and understandable. Clean code and focus around patterns and practices like BDD / DDD are all approaches of bringing the ubiquitous language of the problem domain into the code base. Making it easier to understand how logical business components work. The rules involved and how they interact with other bounded contexts.

Why -Â Conveying whyÂ code is how it is. The intent of the software written. Usually using code comments, separate documentation or even good tests / specifications.

Source control as context

AÂ challenge with code over time, is that it evolves and changes based on requirements and needs. If a team has great discipline then tests / specifications / documentation will evolve with it, but there's always a tendency for that to rot, become stale or even be blatantly wrong.

This is where we can turn to our source control to help. Any given commit in a repository is a snapshot code base, displaying changes to our code and the overall state of that repository. More importantly though, it shows the context in which code was changed.

The context gives us information like when a change was made, who made it, which other files were involved, and where it fits in the history of the repository. This all aids us when trying to understand the context of how the code has evolved to where it is.

Dotting the i

The real magic trick of the source control is the commit message. This message has the power to convey context-aware information that will not change over timeÂ (yes, you can rewrite source-history sometimes, try not to overdo it). But it can convey the intent of a change in a way that gives meaning to a developer.

Writing a message that explains whyÂ a change is being made will make it a lot easier for the next developer (often yourself) to understand the reasoning behind a change.

The message

Herein lies a challenge for many developers. Either they don't really care about the value of good commits and commit messages, or they focus too much on the technicality around micro-commits with technical changes or the message format.

Writing good commit messages is a skill alongside coding that needs to be practiced. Focusing on logical commits that convey thought and intent is where the value lies.

How the messages are formed is a matter of opinion, taste and preferences for the given code base and team, but here are a few resources to get you started.

A note on issue trackers

Issue trackers are awesome when connected to our source control. By explicitly connecting our commits to issues we can have proper discussions and capture a lot more of that said intent. But if you ever change issue-trackers without the possibility of moving history, all that valuable communication is "lost" in the context of reading code.

"Writing good messages is hard"

Writing good messages is hard the same way that writing goodÂ code is hard. You need to understand the "why". Look beyond the user story telling you what to do, and focus on why the change is required to begin with.

committing to it

Why this focus on understandable code through context and communication and writing skills? Unless you're not already convinced that communication and context are valuable to you and your team on a daily basis, there's the fact that developersÂ spend most of their time understanding code.

Look past the technical details of message lengths and how to format a commit message, but rather focus on the value of conveying intent of why changes are being made in a concise and understandable way.

At the end of the day, when all the original developers have moved on and the documentation is out-dated, our source control is where we can look to find the "truth".

Cover-image:Â yuankuei via Visualhunt / CC BY-NC-ND

Efficiency and Effectiveness in Software Development Teams

Pavneet Singh Saund — Wed, 25 Jan 2017 20:23:24 +0000

Efficiency and effectiveness. These two concepts are quite often mixed up. Each with their own strengths and weaknesses. Understanding these concepts will increase the impact of a software developers work.

They come to play in the following quote Â from former Apple CEO, Gil Amelio who said:

Amelio: Â "Apple is like a ship with a hole in the bottom, leaking water, and my job is to get the ship pointed in the right direction."

Smith/Jobs: Â "But what about the hole?"

Before we take apart that quote, let's dig into some definitions!

Efficiency: Doing the thing right

Effectiveness: Doing the right thing!

Amelio is focusing on doing the thing right: "...get the ship pointed in the right direction". But he isn't focused on doing the right thing: "But what about the hole?". So he's focusing on efficiency, and not effectiveness.

Software Development

Now that we have a grasp of the concepts, let's look at how this maps over to he realm of software development teams.

Efficiency

As a single developer, working in a team (or alone). It's easy to get caught up in a cycle of efficiency. Where the mindset and focus is on getting yourself up to a high level of productivity. Such as streamlining how you write code through patterns, practices and looking for repeatable processes. It could also mean having a strong focus on writing quality code. There may also be a tendency to take this too far and optimise code for terseness and not readability..

Effectiveness

The cycle of effectiveness entails more pragmatism and being aware of your context. An effective developer understandsÂ the context of the tasks they are working on. They are then able to make decisions in code based on that context. Such as when and how to make compromises when it comes to code quality / abstractions and implementation details.Â Sometimes whats needed is to take a step back and solve problems without code. Or even removing features.

Teams

Pair & Mob Programming

Most developers have heard of the concept of pair-programming, and even mob-programming. Both are considered as good practices for many reasons. At the same time these practices are also scorned upon by others as inefficient and a waste of time.

Pair-Programming involves 2 people (dev, tester, business etc) working on the same screen. There are many variants, including strong-pairing, driver /navigator, TDD-driven variants and some others. Eric Elliot has a great breakdown on pair-programming.

Mob-Programming is an approach that involves the entire team working on the same screen, and delivering the code in a similar way. The recommended approach is a driver / navigator style where the team serves as navigator and the driver writes what the navigators tell them. I wrote a little about it here.

These approaches sound wasteful and inefficient, especially mob-programming. Yet people argue that these are great way to deliver more value by being more effective. Why? How?

The premise is more eyes on the code written, more knowledge sharing, and a shared sense of ownership. There's also a cross-pollination of disciplines, ideas and shared ownership. Understanding others' limitations and strengths will allow a team to grow even more.

The fundamental drive for these approaches is about being more effective.

Slack and the Utilisation Trap

Henrik Kniberg has producedÂ many articles andÂ videos about the balancing act of delivering value through teams. He's presented two concepts that illustrate the power of an effective mindset; Slack and the Utilisation Trap.

Slack is the absence of work. Where people have Â the opportunity to decide how they want to spend their time for themselves. What may seem counter-intuitive is how much value there is in unplanned time. The idea is that this is where people have the opportunity to "do magic" or innovate. Basically, being effective. Check out Henrik's video on the topic.

The Utilisation Trap relates to slack. It depicts the notion of achieving a highly efficient team, which always has work to do. The focus is to achieve as close to 100% utilised as possible. By lowering the efficiency rate and introducing slack a team can achieve an optimal state of flow. Here's Henrik's video.

Organisations and development processes tend to have a focus on efficiency in their systems. So it's very natural to get stuck in a mindset of efficiency, when what you want is effectiveness. In the rush to be over-effective, it's also easy to bypass efficiency, leading to poorer systems.

My reflections

Focusing on efficiency alone can lead to poor solutions that don't meet the needs of our systems. Focusing on effectiveness alone can lead to inefficient systems that are technically flawed.

As I have grown and evolved as a person and a developer I've felt that my maturity / seniority level matches my focus on effectiveness. In my younger days, it was all about being as efficient as possible, where now I'm focused on being as effective as possible. As I further progress, understanding where and how to be both efficient and effective is where there is the most value. Growing a proactive mindset has been a way for me to realise my impact in the greater context.

As earlier stated in this article, both are valuable, but there's a natural tendency to lean towards efficiency. Instead we should spend more time on practices that make us more effective. As developers, teams and organisations.

What are your experiences with personal or team efficiency and effectiveness? Do you struggle to balance? Leave a comment below, and share this article with someone Â ðŸ’š

This post was originally published on the Coding with Empathy blog

Inspired by conversations with Tomas

Cover photo: Daniel Mennerich via Visualhunt / CC BY-NC-ND

DEV Community: Pavneet Singh Saund

Build dynamic breadcrumb routes and child routes with matchPath in React Router v6

The requirements

TLDR;

Digging into details

Building the breadcrumbs

Matching the top-level crumb with matchPath

Matching children

Edge case 1: Don't match breadcrumb for / - Home route

Edge case 2: Don't match a no-match/catch-all route

Edge case 3 - Child route with ''-path with redirect matches parent route

Rendering routes

Rendering the breadcrumbs

Conclusion

Highlights from the Aurelia vNext 2019 fall update

Adding a /now page

The time is Now

Does Aurelia Support React-like Hooks?

On Observability:

On Dependency Injection:

On Metaprogramming:

Some reflections

Officially backing Aurelia Front-End Framework

Officially backing Aurelia Front-End JavaScript Framework

Why donate to Open Source?

Why Aurelia?

In conclusion

2018 in review

Putting things into perspective

Change, Challenges, and Struggle

Failure

Growth

On a private note

In conclusion

Proof of Concept? MVP? Just tell me when it’s done!

Here’s the deal…

Agile / DevOps / Lean doesn’t mean faster, cheaper or easier

Product Development is Hard

You decide when it’s done.

Finally

Hitting refresh

Tribes — a search for belonging

Tribes

A sense of belonging

The search

Coding with Empathy in 2017

The Blog

The PAVLOG

Conference talks / Podcasts

#goofyreligion

Episode 294 | Reid Evans - Connected Mindset

Developer on Fire

Gratitude

Looking Forward

Controlling the source of truth - The value of better commit messages

Breaking down communication in code

Source control as context

Dotting the i

The message

A note on issue trackers

"Writing good messages is hard"

committing to it

Efficiency and Effectiveness in Software Development Teams

Software Development

Efficiency

Effectiveness

Teams

Pair & Mob Programming

Slack and the Utilisation Trap

My reflections

What are your experiences with personal or team efficiency and effectiveness? Do you struggle to balance? Leave a comment below, and share this article with someone Â ðŸ’š

This post was originally published on the Coding with Empathy blog

Matching the top-level crumb with `matchPath`

Edge case 1: Don't match breadcrumb for `/` - Home route