Having seen a ton of codebases, it's hard to imagine that there are codebases without spaghetti code. A codebase without spaghetti hasn't been around long enough. Sooner or later, code turns into legacy, and technical debt hangs above the heads of the developers having to deal with it. At least when you're not actively taking care of it.

However, it's important to note that technical debt doesn't just impact developers - it can also significantly negatively impact a business in the long term. It can lead to increased costs, slower development times, and a lack of flexibility. It can also lead to a vicious cycle, where developers constantly try to keep up with the technical debt, making it difficult to progress on new projects or updates. That's why recognising legacy code is essential in reducing technical debt. This post will dive into what legacy code is and how to identify it.

This will be hard if you don't use git or any other version control. In that case, I suggest you use git because you can get a ton of information out of your git history.

Before reading on, answer the question: What is legacy code and what has it got to do with technical debt? Then, keep your answer in mind.

Technical debt often describes the cost of maintaining and improving software over time. It usually refers to the trade-offs made during software development, such as choosing to implement a quick and dirty solution instead of a more complex and robust one. This can lead to code that is more complex, harder to understand, and more challenging to maintain. The term "technical debt" conveys that, just like financial debt, there is a cost associated with short-term decisions that must be paid back in the long term.

Software needs to change to ensure it works well for the people using it. As software is used and new requirements arise, it must be modified to meet those needs. However, as software evolves, its complexity increases unless steps are taken to manage it. This is because software systems have many interrelated components, and their relationships become more complex as they change. That's the two first rules of Lehman's laws of software evolution. There are eight of these laws in total, each addressing a different aspect of software evolution. Together, they provide a comprehensive understanding of how software evolves and how to manage that evolution to ensure it continues to meet the needs of its users. The first two make an obvious point. Things get complicated as time goes on.

One of the crucial things to look at when dealing with technical debt is code complexity, but what defines code complexity?

Factors that contribute to code complexity include the length of the code, the use of nested loops and conditional statements, the number of types and variables, and the level of abstraction in the code. However, code complexity is not the most significant contributor to technical debt. If you have a large complex file in your codebase that hasn't been touched in ages, it seems less problematic than a file that's actively changed all the time. To tackle technical debt, you must find the parts where code complexity is an issue and is most actively worked on. Those are the files that you need to prioritise.

You can use that same logic on a function level if you have a huge file that seems to be one of the files you need to prioritise. Refactoring gigantic files is risky and should be done carefully.

Legacy code is usually described as old, outdated, or no longer supported by the original developer. And whilst often legacy code is seen as more complex, it is often a case of not being familiar with the code rather than complexity. In each team, only a few people write most of the code. If they depart and the remaining team members are unfamiliar with that portion of the code, it can quickly become legacy.

Legacy and technical debt are not the same things, but legacy, in fact, is just a part of technical debt. It's the knowledge you lose when a developer leaves.

Technical debt is more than just bad decisions. It's an entire ecosystem based on multiple factors. It's the complexity of a codebase contains the relevance of parts of the code and individual developers' knowledge. The latter is the hardest one to tackle and the most expensive one to fix.

Conquering the legacy code and technical debt conundrum

Deciding to go freelance is never easy, but after careful consideration and
reflection, I have decided to take the plunge and transition to freelance work
in 2023. This is the right choice for me, and I am excited about the
opportunities and challenges it will bring.

One of the main reasons I am excited about going freelance is the freedom and
flexibility it offers. As a freelancer, I can choose the projects I work on and
the clients I work with. This allows me to tailor my work to my strengths and
interests and to select projects that align with my values and goals. In
addition, I'm eager to share my expertise in technologies such as JavaScript,
TypeScript, and React.

I look forward to the opportunity to take on work that I am passionate about and
that will be meaningful and fulfilling. In addition to my programming skills, I
also have a strong background in UX and design. Furthermore, I am skilled at
creating user-friendly and visually appealing interfaces, which will be a
valuable asset as a freelancer.

Another reason I am looking forward to going freelance is the opportunity to
build close relationships with my clients. As a freelancer, I can work more
closely with my clients and connect personally with them. This will lead to a
more collaborative and productive working relationship and allow me to better understand my client's needs and expectations.

I also have much support from the people close to me. My friends and family have
been incredibly supportive of my decision to freelance, and I am grateful for
their encouragement and belief in me. They have provided me with the confidence
and motivation to take this step and pursue my dreams.

Of course, going freelance has its challenges. There will be times when I have
to work longer hours and take on more responsibility, and there will be times
when I have to deal with the ups and downs of self-employment. But I am ready to
embrace these challenges and learn from them. Going freelance will allow me to
grow personally and professionally, and I am excited to see where it takes me.

Overall, I look forward to this new chapter in my career and am excited about
the opportunities and relationships going freelance will bring. I am ready to
embrace the challenges and opportunities that come with it, and I am confident
this is the right choice for me.

Why I decided to go freelance in 2023 and beyond

At the time of posting this article, Kapsalon Lieve has just launched its
website. Having a website helps people find your contact information.

Under the hood, the website is built with NextJS and a git-based headless CMS:
Tina.

Currently, the website is a one-pager mainly for discoverability on the
internet. However, the website can quickly scale with the CMS providing the
data.

Do you like how this website turned out? Or do you want to talk about it?

Button

A new website for Kapsalon Lieve

Throughout the years, I've worked with all sorts of tooling to keep track of
progress and issues within a team.

I've used simple tools like Trello boards, Github issues and post-its. I've also
used more extensive tools like JIRA, ClickUp, custom software and many more.

Spoiler alert: As a developer, I am 100% biased, and I haven't much to say about
extensive tools like JIRA.Tools like JIRA get a lot of hate. That's because
developers mainly don't like having their work parcelled out so precisely. But
let's get this out of the way. Tools like JIRA are not for them. It's for
stakeholders, managers and people who have to report progress and who are
responsible for budgets.

I will not be bashing on Project-Management tools in this post, but I will
address what I like about simple tools.

When you accept that PM tools exist for people responsible for budgets, what
happens when the budget is a non-issue?

Open source teams can grow enormous, where people worldwide work on the same
project. At the same time, people from all over the world can bring issues to
the table which need attention.

Those projects seem to manage fine without a mastodont of an application.

The way GitHub manages issues is one of those ways I like as a developer. It's
easy; Somebody can use it to discuss things, you can address and tag people, and
it keeps track of your codebase throughout discussions.

A Kanban board is the only thing I missed for it to be perfect. That's where the
simplicity of Trello was lord and master. Trello was and still is, easy to
configure and fully customizable to anyone's needs.

GitHub recently introduced GitHub Planning.

Create issues, break them into tasks, track relationships, add custom fields,
and have conversations. Visualize large projects as spreadsheets or boards,
and automate everything with code.

That's everything and more of what I'm looking for in a tool. It's simple,
elegant and close to the codebase. Best of all, you don't need a half-baked
integration that only works if you make your commit history bloated.

We established that extensive tools are made for Project Managers. However,
GitHub is a platform created for developers, and they have made a platform that
comes developer-first.

It does that by building its solution around the code and not the other way
around. The code is the heart of the project, and issues, features and planning
come on top of that.

In my opinion, the end user of the system is the developer. They are the people
that work with it the most and rely on history for context surrounding a
codebase. Unfortunately, they are also the people hating on tooling like JIRA.
It is worth listening to those people.

I'm not saying tools like JIRA are redundant because they are not. However, as a
developer, I'm convinced that if they rethink their flow and build it
developer-first, they will have a better product. And as a result, project
managers would also have an easier time.

The love and hate relationship between developers and project management tools

Equilibra just launched its new website. It's one of the first websites I
created using the Remix with Sanity stack. I love developing with Remix, mainly
because the development flow is smooth.

The website runs fast, with lighthouse scores above 90. Remix powers the website
behind the hood, and the CMS system is Sanity.

One of the challenges for Equilibra was the fact they have a lot of different
treatments and prices. So it was essential to maintain the overview and clearly
show the costs to those looking for them. So we talked things through, and it
was clear that there are different kinds of treatments, so we grouped them.

The inspiration for pricing came from how many software products show their
pricing because they usually have a way of showing prices that is easy to
compare different tiers of pricing. So those are things that are important for
Equilibra as well. 

I'm happy with how the website turned out, and most importantly, the customer is
too.

A new website for Equilibra

Web development is an area of expertise where things change quickly. But,
unfortunately, not much stays the same. In a world where decision fatigue is
expected, and the internet throws you stuff at the speed of light, having the
proper resources might help reduce the number of triggers thrown at your brain.

Being a web developer and not enjoying web development is a hard thing to do. So
if you're a web developer, you should find something to do that motivates you.
Businesses are not waiting for you. It's in your best interest to stay
up-to-date. Sticking to what you know means falling behind.

I'm not here trying to scare you. I'm in the same boat, and sometimes it feels
like a lot is going on to filter through. For one, it's OK not to know
everything. It's more important to follow what you like and keep you motivated.
An overload of information will do the opposite. I will share some things to
stay up-to-date and motivated to learn something. Learning things and going
outside your comfort zone once in a while is fun!

There are a lot of developers in the world. And a lot of them are visible
throughout the internet. I'm far from the biggest fan of social media, but
Twitter is an excellent resource for staying up-to-date with web development.

, and I started
following only those who share web dev-related stuff.

Scrolling through my timeline brings me joy because I discover stuff I wouldn't
have had without it. It shows me things I like because I only follow the people
who interest me. I also follow the platforms I work with because they share when
a new update comes out. In other words, Twitter is just a newsfeed to discover
stuff.

Looking at people's GitHub profiles also gives you a ton of information. I
discovered prisma.io just browsing someone's profile, and I thought, this looks
fun.

Podcasts seem to become popular at the moment. That's because they are fun to
listen to. Even for web development, there are a lot of podcasts out
there. 


long ago, and I still listen to the same ones. I think listening to people
talking about the stuff you love is fun. Sometimes people talk about stuff where
you think: Well, I'll look that up!

, you will
undoubtedly end up in an issue thread. If it's about a topic you care about,
subscribe to it. You can always unsubscribe the moment you stop caring about the
issue. Your interests will change with time, so there is nothing wrong with
subscribing/unsubscribing.

Discord is well known, especially in the gaming community, but Discord is so
much more than that. It's a tool for creating communities.

A lot of open-source projects have got a discord community. And I have been
helped fast by asking a question in those. The only problem with Discord is that
it does not get indexed by Google and other search engines. As an example,
someone helped me with an issue. It will be harder to find a solution when
another developer has the same problem. So it's a bit of a golden cage.

Like discord communities, some open source projects have their community based
on Slack. However, Slack has similar pros and cons to Discord: you're getting
help fast, but it's harder to track solutions to other people's issues.

It's essential to stay up-to-date when you call yourself a web developer.
Especially when it comes to new features, technologies, trends, tools, best
practices, and so much more, it's OK not to know everything there is to know
because otherwise, you will burn yourself out. In other words, it's essential to
have the right resources to stay motivated, learn, and, most importantly, keep
up-to-date.

I've listed the most significant resources I use, and maybe they inspire you to
find your own.

Keeping up to date with the latest web development trends

Clean git history is essential because it helps to make it easier to understand the evolution of a project. When history is cluttered with unnecessary commits and merge conflicts, it can be challenging to understand what changes were made and why they were made. A clean history can also make it easier to revert to previous versions of the project, as it is easier to find specific commits when the history is organized. 

Overall, a clean git history is essential for the maintainability and understandability of a project.

A bad git history can take many forms, but some common characteristics include the following:

In general, a horrible git history is challenging to understand and navigate. It may also indicate poor coding practices, such as a lack of testing or focus on code organization.

Here are some examples of what I consider lousy git commit messages:

Good git commit messages follow a few best practices:

Here are some examples of good commit messages:

In general, good commit messages are specific and informative and help provide context about the changes that were made. This makes it easier for others to understand the project's evolution and collaborate effectively.

 are a structured way of writing commit messages that makes it easier to generate changelogs, release notes, and other documentation automatically. The goal of using conventional commits is to make it easier to understand the changes that have been made to a project and to allow tools to understand the intent of each commit more easily. Those things work because the way the commit messages are written is predictable. That also means humans can easily read and understand them.

Several conventions for formatting commit messages have been established as best practices. One widely used convention is the Angular convention, which defines the following structure for commit messages:

The type is a short, all-lowercase string that describes the nature of the commit. Some common types include:

The scope is an optional string that describes the part of the codebase that the commit affects.

The subject is a brief description of the changes made in the commit. It should be written in an imperative mood and should not exceed 50 characters.

For example, a commit message following the Angular convention might look like this:

The body of a conventional commit is optional and is used to provide a more detailed description of the changes made. It should be used to explain the motivation for the changes, as well as any implementation details that may be relevant.

The body of the commit should be separated from the subject by a blank line and wrapped to a maximum line length of 72 characters.

Here is an example of a commit message with a body:

In general, the body of a commit message should provide enough information to understand the changes and motivations behind them without going into unnecessary detail.

In conventional commits, breaking changes are indicated by including the word "BREAKING CHANGE" in the commit message, followed by a colon and a description of the breaking change.

The description of the breaking change should explain the change's impact and any steps users will need to take to migrate to the new version.

You can also append '!' to the scope/type to get the same result:

Writing the perfect git commit message

Remix.run is the (or not, to be confirmed) hot new Full Stack React framework
around the block. A few knowledgeable engineers hype it at the moment. It should
be noted that the founders 

 are mostly known for React
Router, UNPKG, and Reach UI. Moreover,


has recently joined the team as
director of developer experience to throw some more wood on the fire. Many
developers have used at least one or more things that they made.

In this post, I will be talking about the following:

The entire idea behind Remix is that everything is server-rendered. As someone
who has spent much time using things like 

, going mainly SSR is somewhat different.

To begin, their website says: Remix – Build better websites. Saying something
like that lifts the expectations and raises the bar to a high level, especially
when the competition for creating websites is enormous. NextJS, in particular,
is probably the closest competitor for what Remix is trying to do. Moreover, I
will not be comparing Remix with something like Gatsby, as Remix isn't a Static
Site generator. Instead, the focus of Remix is server-side rendering, and even
though you can use NextJS as an SSG, it has server rendering and does a lot of
the same stuff Remix does, but differently.

I have mixed feelings about the initial setup. So let me carry you through this.
Firstly, you do this in your terminal:

Following this, you see a fancy Remix animation in the console and a menu where
you need to choose where to deploy your application. Depending on your pick, you
get a project with different configuration files pre-made for the platform you
will deploy. On the one hand, if you want to change hosting, you need to think
about what needs to change to run it on the other platform. On the other hand,
it doesn't feel great.

On the other hand, it does save you configuration time, it's easy, and the
animated logo in the terminal looks pretty. Let's talk about the essential thing
about Remix.

Firstly, routes are the most significant thing about Remix. To me, it feels like
every route is a server route and conveniently has the option to render a
client-side UI if you want. In essence, everything in Remix is about routes, and
that's not a surprise if you look at the people that founded Remix.

Every route is a server route and conveniently has the option to render a
client-side UI if you want.

Basically, on every route, you have the option to export things. So, for
example, you can render a front-end, get data from somewhere, generate an RSS
feed, or submit a form based on those things.

Just going over the basics, these are things you can expect from a route:

I'm not going to elaborate on the functionalities of Routes (nested routes,
parameters, …), but those are things you want to take a look at once you know
the basics.

Loaders are the backbone of the route, as they do all the heavy lifting.
Therefore, you want to return to everything related to the data you need in this
function's front end.

The idea behind a loader is that you can do more than return data for a route.
You can send complete responses, including cache control headers. When you set
cache headers on your response, the same route will get the cache if the route
has already been fetched.

If loaders are the backbone, the client-UI is the frontal bone. In particular,
the part you export as default is where you render your front end. So if you
have fetched some data inside your Loader, you can get it here and render it for
your visitors.

Getting the data from the Loader is pretty straightforward:

Everything else in the default export is basic JSX, putting components where you
want them, and so on.

At this point, you could make your entire full-stack application with just these
two things. In addition, RRemix makes the communication between the front- and
back end pretty darn easy. You can fetch data from any API, and since it is
server-side-rendered, you can fetch data with secret keys without worrying about
exposing your secrets.

Remix makes the communication between the front- and back-end pretty darn
easy.

Last but not least, actions. Actions are where things get interesting. Action is
a server-only function where you can handle actions. It is the same as Loader;
the only difference is when it's called. The action is called before the loaders
if a non-GET request is made to your route (POST, PUT, PATCH, DELETE).

For example, an action could be submitting a form to subscribe to a newsletter.

First, we create a simple form like this:

, with a few goodies. If
JavaScript is turned off, the form will still work. Remember, the default form
only supports GET en POST, so you should probably stick to those if you’re using
a form.

And then, we create a server-side Action to handle the form submission. When no


 is provided to a form, it will submit to the page itself.

To get back to the front end, you can receive the responses from the action in a
few ways, one of them being useActionData.

When a POST is made to a URL, multiple routes in your route hierarchy will match
the URL. Unlike GET to loaders, where all of them are called to build the UI,
only one action is called.

) will automatically post to
the same route within which they are rendered.

My first thought was: Oh, you can build an entire API like that. Nice. It’s the


 folder in NextJS (if you are familiar) but throughout the entire routing
folder. Moreover, every route has the option to render a front end. That’s
amazing.

With loaders and front-end rendering, you have all the basics to make an
application. Everything else is improving the UX of the application.

Remix doesn’t stop at Loaders and Actions. My first impressions do, however. If
you want to know more about Remix (like nested routes, Error handling, and so
much more), I would strongly suggest looking at their website:


Honestly, I can say that I’m hyped. I am a fan of serverless and JAMStack, so I
started sceptically. Remix.run, to me, feels like you are working inside a web
framework, not a React framework. You so happen to be, are working with React on
top of it. Moreover, I have learned about Javascript in my adventure learning
Remix, and I’m not done using it. It is promising without a doubt.

In conclusion, a lot of things make sense. Thinking about what happens on the
server and what doesn’t is something extra to think about, but that might be a
good thing.

If you are a fan of magic, I recommend you to stick to NextJS (or Gatsby for
even more magic) or whatever framework you are using now. But if you like
bare-boned where you have control over everything, Remix might be your tool.

frrrip throwing remix.run into the mix my first impressions

In contrast to what the title might indicate, this blog post is not the start of
a joke. Instead of dad joking around, I want to talk about casing in naming in
programming.

Only interested in the short version about how I name my stuff in programming.
Skip to the conclusion. If you want to go for the full story, keep on reading.
Let’s dive in.

In programming, spaces are a kind of character that is reserved. You can’t use
spaces in variables, so we replace the spacing with something that allows us to
still read it.

For example, if you declare a variable to indicate the visible item count:

Javascript would try to treat every word as a different concept. This means it
treats visible, item, and count as individuals.

In conclusion, removing spaces is something you cannot ignore in programming. In
this blog, I will share my thoughts about different kinds of ways to remove
spacing from words, but I will mainly focus on how I think you should name your
files.

To use camelCase, you strip the spaces from your words and capitalize every word
except the first.

This way of capitalizing is commonly used for variable declaration.

To write something in Pascal-Case, you start every word with capital and remove
the spacing.

You can write something as kebab-case by turning everything lowercase and
replacing spaces with dashes (-).

This is commonly used to write readable URLs
(example.com/blog/title-of-the-blog-post).

Camel Case seems to have become the standard for naming files in front-end
development. Why is that?

Over the past years, I had a few naming conventions. For instance, I used Pascal
Case for components, kebab-case for utilities, and camelCase for everything
else. This way, I could expect what was inside the file without opening it. I
like the idea, but things get tricky when stuff changes. FYI, file systems that
are by default case insensitive, like macOS, have issues when changing caps and
submitting them to your repo. It’s a recipe for failure at one point or another.
There is always a way to fix it, but in my opinion, it’s not worth the hassle.
If I have to rely on the file name casing to know what I would expect inside the
file, it would probably mean there are issues in my project structure in the
first place.

Over time, I switched to all lower cases (kebab), and I love it. In essence,
these are the key benefits of kebab as opposed to camelCase:

To me, it seems like a small tradeoff for a lot of benefits.

In addition, I’m not the only developer thinking this way. For example, Kent C.
Dodds replied to a tweet about someone who had an issue with capitalization when
his application was deployed to a (most likely) Linux server.

Conclusion: my preferred naming conventions

Long story short, this is how I like to name stuff in my codespaces nowadays:

What’s your preferred naming convention? Let me know!

A kebab, a camel, and pascal walked into a codespace

While working at Wheelhouse, I got the chance to create a website for 

raccoons

Raccoons are a diverse ecosystem of thinkers, doers, and techies, continually reimagining what's possible to make a difference in people's lives today and tomorrow.

Raccoons are a highly respected and successful company specializing in a wide range of services and products. Their dedication to staying at the forefront of their industry has allowed them to consistently offer innovative solutions to their clients, utilizing the latest technologies and techniques. In addition to creating and maintaining their products, the team at Raccoons is always looking for ways to improve and evolve to meet the changing needs of their customers.

One of the biggest challenges that Raccoons faced when developing their website was ensuring that it was user-friendly and easy to navigate. With so much information available, it was essential to find a way to present it in a clear and organized manner. Through careful planning and design, Raccoons created a website that is visually appealing but also intuitive and efficient for users.

The team at Raccoons is passionate about various topics, and they have channelled that enthusiasm into a successful podcast called Radio Raccoons. Each episode delves into a subject that the Raccoons team cares about, offering unique insights and engaging discussions. So whether you're interested in the latest tech trends, the inner workings of the business world, or want to be entertained, Radio Raccoons has something for everyone. So tune in and join the conversation with the dynamic and knowledgeable team at Raccoons.

Gatsby is a free, open-source framework based on React that helps developers build fast and modern websites and applications. It is designed to be easy to use and allows developers to get up and running quickly, with a focus on performance and scalability.

Emotion is a library for styling components in React using CSS-in-JS techniques. It allows developers to style their components using JavaScript objects, making it easy to create and manage styles in a modular and reusable way.

Sanity is a headless content management system (CMS) that provides a flexible and powerful platform for building and managing digital content. It is designed to be easy to use. It allows developers to create custom content-driven applications, such as websites and apps, using a powerful API and a customizable studio interface.

Introducing raccoons.be a website created with Gatsby, emotion and sanity

wheelhouse.be

, I thought a javascript-focused workplace needed to create a website up to par.

As a Javascript consultancy agency, Wheelhouse is committed to using the latest and most effective technologies to deliver top-quality services to its clients. That's why the website was built with React, Gatsby, and styled-components - powerful tools that enable the creation of fast, user-friendly, and visually appealing websites and applications.

The main focus of the website was to improve employer branding. To achieve this, I decided to showcase our team and encourage collaboration on the website. One way I did this was by introducing a feature called "the picks of the month," inspired by the podcast Syntax's "sick picks" segment. This feature highlights the team members' favourite products, resources, or tools, with the goal of giving insight into their work and personalities. By involving my colleagues this way, we created a more personal and engaging experience for visitors to the website.

React is a JavaScript library for building user interfaces. It allows developers to create reusable components that can be rendered on the server or the client. 

Gatsby is a free and open-source framework based on React that helps developers build fast, modern websites and apps. It uses GraphQL and static site generation to develop and deploy performant sites, and it offers a wide range of plugins and integrations to customize and extend its functionality.

Styled-components is a popular library for styling React components. It allows developers to write CSS styles in JavaScript and apply them to their components. It provides several benefits over traditional CSS approaches, such as improved readability and modularity. In addition, with styled-components, developers can easily create and manage styles for their components in a way that is both efficient and maintainable.

Introducing Wheelhouse A website built with React, Gatsby, and styled-components

Hire me

Daren Malfait

Hi, I'm Daren

Web development is the process of building and maintaining websites and applications.

Webdevelopment

User experience is crucial because it affects customer satisfaction and loyalty.

User experience

Developer experience, or DX, is essential because it can affect a developer's productivity, satisfaction, and overall effectiveness in creating and maintaining software.

Developer experience

Code auditing is reviewing and evaluating code to identify and fix issues, improve performance, and ensure compliance with coding standards.

Code auditing

You can hire me for:

What do I do?

Tools & Techs

For you to read

Latest blog articles

Home

DarenUI

Remmy

This command uses ESLint to lint JavaScript, JSX, TypeScript, and TSX files in the current directory. It then filters the output only to show the files that contain a specified string (in this case, "darenmalfait" because that's a string all my paths have) and opens them in Visual Studio Code.

This command uses several command line tools to perform several actions:

This page contains a command using ESLint to lint JavaScript, JSX, TypeScript, and TSX files in the current directory. It then filters the output only to show the files that contain a specified string and opens them in Visual Studio Code.

a oneliner to open all files with linting issues in vs-code

useReducer Is a hook in React that is used for managing the state in a functional component. It is similar to useState, but is more powerful and can be used for managing more complex state changes.

Here's an example of how you might use useReducer in a React component:

In this example, we have a counter that increments and decrements based on the actions dispatched by the buttons. The reducer function is responsible for updating the state based on the actions.

 works, we can change it into something flexible. I tend to use this if my component has a lot of states that belong together. It's cleaner than 

Snippet for a flexible useReducer in React.js

Flexible useReducer in Reactjs

You can convert markdown files to pdf files with 

If you have a folder filled with markdown files. You can convert an entire folder with:

This page contains snippets to convert markdown files to pdf via an npm package.

Convert markdown files to pdf using npm

Environment variables are variables that contain information that is used by the operating system and other programs. They are typically used to store configuration data or pass information to programs when launched. Environment variables are usually stored as key-value pairs, with the key representing the variable's name and the value representing the variable's contents.

There are a few different ways to set and use environment variables. One way is to set them in the operating system's environment. This can be done through the command line or a configuration file. For example, on a Unix-based system, you can use the "export" command to set an environment variable like this:

You can also set environment variables for a specific program or script using a configuration file or specifying them on the command line when you launch the program.