DEV Community: Ryan Fitzgerald

Becoming an AI-native engineer

Ryan Fitzgerald — Thu, 12 Jun 2025 15:00:26 +0000

I’m confident I’m not alone in saying I’ve spent a lot of time over the past couple of years thinking about AI as an engineer / developer and what it means for our field and for our careers. For a long time, software engineering felt like a safe bet. After all, how could we be automated away when we’re the ones writing the automation? Or so we thought.

Like many, I’ve run the full gamut of emotions on the topic: excitement, uncertainty, fear, frustration, more excitement, more uncertainty, and so on. If there's an emotional response to AI to be had, I’ve probably felt it. But lately, one emotion has consistently stuck, and that’s excitement.

It took a while to get here (and arguably even longer to learn to stay here) but I can now say with confidence: the rise of AI excites me more than anything else right now as an engineer. The opportunities seem endless. Things have started to click.

I’ve always considered myself a fairly effective engineer by traditional metrics...shipping consistently with quality, solving challenging technical problems, mentoring others. But with AI, I’m producing more than ever before, with a level of speed, quality, and understanding I’ve never experienced. In many ways, it’s 10x’d me as an engineer.

The next sections of this post are my take on what it takes to become an AI-native software engineer and build fluency with AI at every level. I’m not claiming to have mastered it all (far from it) but I wanted to put my thoughts down in the hope that they might help another engineer or two get off the emotional rollercoaster and land on excitement.

This post is less about specific tools and frameworks (though I’ll sprinkle in a few I've found) and more about the mental models needed to approach AI effectively. As I keep learning and refining my thinking (and as the space continues to evolve), I’ll aim to share more. For now, think of this as a brain dump of random thoughts I have on how I currently view AI’s role in modern software engineering.

It starts with a mindset shift

The best way I can explain my mindset is that I see AI as a multiplier of myself, not just a tool that does work for me on command (though I'll admit “vibe coding” can be fun occasionally).

Put another way: a junior engineer might only have the experience to ask AI questions that yield intermediate or senior-level responses. But a senior engineer, with deeper context and stronger instincts and understanding, can frame questions in ways that push the AI to think more like a Staff or Principal engineer, bringing a much sharper lens to the same problem.

As your experience grows, so does your ability to prompt effectively and with that, the multiplier effect of AI scales alongside you. That’s why I often say I feel like I've 10x’d myself as an engineer. It’s like having a far more seasoned engineer in my corner with far more knowledge and context than I do, ready to answer any question or help debug any issue I run into. And the best part? I can't ever catch up to them; they stay steps ahead.

The power of a good prompt

Building on the previous point about how experience shapes AI output, it’s worth emphasizing that effective prompting is critical at every level. Even if you're more junior, you might not always know what to ask but that doesn't mean you can't learn how to ask it well with the experience you have.

We’ve all seen it: you ask an LLM for code, and it spits out something completely unusable...maybe even the worst code you’ve ever seen. Is that the model’s fault? Maybe. But more often than not, it’s a sign that the prompt wasn’t clear or specific enough. With better framing, you can guide the model toward a much more useful and accurate response.

Let’s walk through a quick example to illustrate this. Say you’ve built a simple React LoginForm component and want to save time by having AI write the tests for it. So you type:

Can you write tests for my React component?

Sure, the LLM will likely produce something, but chances are, it won’t be very good. Why? Because it has almost no context. It doesn’t know what the component does (it has to figure it out based on the code), what you’re trying to test, or what your expectations are. It’s forced to guess, and the result will reflect that. It might technically “work” but it definitely won’t be optimal. You can do better and save time spent reworking it later.

Now compare that to a more thoughtful prompt:

I built this LoginForm React component that includes an email field, a password field, and a submit. It also includes a success and error state based on the result after calling onSubmit. Can you write a test that: 1. renders the form, 2. fills in valid and invalid data 3. submits the form, 4. asserts that onSubmit was called with the correct payload, and 5. checks both the success and error state render correctly as a result.

This takes only a bit more time to write, but the quality of the response will be exponentially better. The takeaway? Don’t cut corners on your prompt. A little extra effort upfront goes a long way.

Another tip is if you're using an IDE like Cursor, take advantage of things like .cursorrules to define project specific instructions. These give the LLM important context about your codebase and conventions you're looking to follow. Also, make use of the Ask vs. Agent modes. Starting in Ask mode helps ensure the LLM fully understands your intentions before it starts generating or editing code. It may take a bit more time upfront, but it can save you from a lot of rework, confusion, and low-quality code suggestions that you ultimately end up rejecting.

Trust, but verify

This one might seem like common sense and in some sense contradictory to previous statements, but it’s worth repeating: AI-generated output, especially code, should never be blindly trusted. You’ve probably heard stories (more often than you’d like) of someone who "vibe coded" their authentication layer, only to have it exploited later by a third party.

More often, the risk is subtler: the AI generates a block of code, you give it a quick skim, and it seems fine...so you ship it. But now you’ve got a production bug in code you don’t fully understand because you didn’t actually write it.

AI-generated code is not bulletproof. Far from it. As previously discussed, the quality of the output is heavily dependent on the quality of your prompt. That’s why it’s critical to review everything carefully. Make sure you fully understand what the code is doing. Don’t hesitate to ask the LLM follow-up questions or have it review its own output for potential bugs or optimizations. Treat fully generated code (no matter how complex) like it was produced by a junior engineer: helpful, but in need of oversight.

Also, don’t be afraid to push back and provide feedback based on your own experience. Just because AI can act as a multiplier and draws from a broader base of knowledge, doesn’t mean your expertise isn’t valuable. Trust your instincts and experience.

It’s not uncommon for AI-generated code to be unnecessarily over-engineered. For example, I recently asked it to help with DNS lookups in Node.js, and I wanted the operation to timeout after a set number of seconds. The AI’s response was mostly correct, but for the timeout, it built a fully manual workaround. Fortunately, I had used the library before and knew it supported a built-in timeout option. I shared that with the model, and it simplified the solution accordingly.

Code generation vs. deeper understanding

The power of AI goes far beyond just generating code for engineers. While that’s certainly one of its most impressive capabilities, it shouldn’t be the only way you benefit from it. One of the most underrated use cases is using AI to help you understand complex topics...breaking down ideas, explaining unfamiliar concepts, or walking through problems step-by-step.

For example, want to support custom domains for your customers but aren’t sure where to start with DNS configuration or SSL certificate generation? Or maybe you're trying to set up scalable email infrastructure? Or manage large volumes of data efficiently? These are all tasks that, in the past, would have required extensive research, lots of trial and error, or a more experienced engineer to walk you through. With AI, those learning curves can shrink from days or weeks to potentially hours.

AI is an incredible tool not just for generating code, but for helping engineers understand architectural patterns, validate existing systems, and solidify their understanding of complex topics. Use it for those purposes just as much as you use it to write code.

That said, the same caution applies: don’t take architectural advice at face value, especially in areas where your own experience is limited. Just like you’d review AI-generated code before shipping it, review architectural suggestions carefully and make sure you truly understand the tradeoffs before adopting them.

Never stop learning

As engineers, continuous learning tends to come naturally but in the context of AI, it’s absolutely essential. The landscape is evolving at an incredible pace, and the tools, frameworks, and capabilities available today might look completely different a year from now. Staying current with the latest developments, trends, and techniques is key to remaining effective and fluent.

To keep up, I rely on a mix of resources: newsletters, blogs, X (Twitter) accounts, and even Reddit threads. These help surface what's new, what’s gaining traction, and what’s worth exploring further.

There are also plenty of excellent resources available for deeper learning...whether you want to explore specific topics, understand the inner workings of LLMs, or sharpen your skills with real-world examples. Whether you're casually exploring or diving deep, there’s no shortage of high-quality content to learn from.

Quick plug: If you're looking for a curated source to stay up-to-date with the latest AI news, trends, and tools for busy developers, I publish a weekly AI Dev Roundup newsletter. No fluff, just the good stuff. It's effectively a collection of what I find throughout the week. Check it out →

Finding the right tools

Finding the right tools for your AI workflows is a personal process and it’s highly subjective. It depends on how you like to work. My best advice: try as many tools as you can and see what fits your style and needs best.

At the IDE level, there are some excellent options like Cursor, Windsurf, and GitHub Copilot in VS Code. Each has its own strengths, and it’s worth exploring what makes each one unique. There are also cost components to each if you want to leverage all features.

Beyond IDEs, there are also powerful standalone AI agents built for software engineering tasks. Tools like Claude Code, Cline, OpenAI Codex, and others. These can be great companions for deeper problem-solving, architecture planning, or even long-form code generation.

Once you find a tool that clicks, become a power user. Learn its strengths, shortcuts, and workflows. Personally, I’ve landed on Cursor. It’s an incredibly capable AI IDE that covers everything I need and then some. I also appreciate how active their team is in the community and how committed they are to continually improving the product for engineers.

Another important factor to consider is the models themselves. It’s well worth experimenting with different models and staying up to date on which ones perform best for software engineering tasks because this changes often.

Some models are stronger at reasoning, others at code generation, and some handle multi-step tasks more effectively. Knowing which model excels in which area can give you a serious edge especially in tools like Cursor, where you can choose which model powers your agent.

Build. Build. Build some more.

This one almost goes without saying: build. Then build some more. The best way to understand what’s possible with AI as an engineer is to experiment. Try building new things, use AI in different ways, create powerful workflows, and explore not only its strengths but begin to understand its limitations.

The more you apply it hands-on, the better you'll understand where it excels, where it falls short, and how to get the most out of it. That’s how you truly become AI-native as an engineer.

Building with AI isn’t just about generating code, it’s also about building products that integrate AI at their core. Some of my biggest leaps in understanding came from working directly with AI inside real products, especially when implementing agentic workflows using frameworks like LangGraph. The more you're in the weeds, the more you're forced to learn, experiment, and debug.

Working with AI in this way forces you to think about system design, user interaction, reliability, and how AI fits into real-world use cases, which is where the deeper learning really happens. It also very quickly reinforces the power of a strong prompt.

It's not always all about the code

Being an AI-native engineer isn’t just about generating code. Sure, you might already use it to draft emails, write pull request descriptions, or even respond to Slack messages, but there are many powerful use cases that often get overlooked.

For example, imagine you’re in a meeting discussing a major architectural decision, and you notice some serious flaws in the proposed approach. Maybe you're experiencing some difficulty trying to articulate your concerns in a way that resonates with the team. That’s a perfect moment to leverage AI: give it context, explain your concerns, and let it help you dig deeper, explore the implications, and even frame your argument more clearly and persuasively.

The point is, AI doesn’t just have to help you write or understand code, it can support you in every facet of your role as an engineer.

Wrap up

I know this was more of a high-level piece, but I hope it offered some useful mindsets or mental models for applying AI as a software engineer. If you found it helpful or have any feedback, I’d love to hear from you. I plan to continue writing on this topic, talking about AI workflows as an engineer, and may dive deeper into specific areas in future posts as well.

Why your team probably doesn't need a synchronous standup

Ryan Fitzgerald — Tue, 03 Oct 2023 01:31:08 +0000

In recent years, the landscape of remote work and collaboration has changed considerably, and with that, the way teams communicate and share updates has also undergone a bit of a transformation. Traditional synchronous standup meetings, a staple in many workplaces, are increasingly being challenged by the more flexible and efficient approach of asynchronous standup options. In this blog post, we will explore why asynchronous standups might be the way forward for your team.

The Rise of Asynchronous Work

The shift towards asynchronous work has been driven by the growing acceptance of remote work, especially since the pandemic. With team members spread across different time zones and schedules, it becomes challenging to coordinate meetings that suit everyone. Asynchronous work acknowledges and embraces this reality, allowing individuals to contribute when it's convenient for them.

Flexibility and Inclusivity

One of the significant advantages of asynchronous standups is the flexibility they offer. Team members can participate in the standup at their own pace, eliminating the need to synchronize schedules with the rest of the team. This inclusivity is particularly important when you have team members located in different regions or those with varying work-hour preferences.

In contrast, traditional synchronous standups can inadvertently exclude team members who cannot attend due to conflicting schedules or time zone differences. Asynchronous standups ensure that everyone has an equal opportunity to contribute and stay updated.

Standup Automation

The increasing popularity of asynchronous standups has given rise to a number of popular tools that help automate the async standup process in existing tools your team probably already uses, such as Slack. For example, tools like StandupWizard will message your team on Slack individually at your defined schedule and post their responses to a central channel for all to see, among other features.

Enhanced Productivity

Asynchronous standups can also boost productivity by minimizing interruptions. In a traditional standup, everyone is expected to be present and attentive at the same time. This can disrupt the flow of individual work and lead to productivity losses. With asynchronous standups, team members can choose when to review and respond to updates, allowing them to allocate their focus where it's needed most.

Better Preparedness

Asynchronous standups encourage team members to think more carefully about their updates. When sharing their progress in a written or recorded format, they have the time to articulate their thoughts clearly and concisely. This leads to more meaningful contributions and a better understanding of each team member's responsibilities and progress.

Improved Documentation

Documentation is a key aspect of effective project management. Asynchronous standups naturally generate written or recorded updates, creating a valuable record of the team's activities and decisions. This documentation can be referenced in the future, serving as a knowledge base for new team members or for reviewing past projects and their outcomes.

Overcoming Time Zone Challenges

For globally distributed teams, asynchronous standups are a lifesaver. Team members can provide updates without needing to be online at the same time. This eliminates the challenges associated with time zones and makes collaboration more seamless and efficient.

Conclusion

While asynchronous standups offer a wide array of benefits, it's important to acknowledge that they may not be suitable for every team or situation. The transition from traditional synchronous standups to asynchronous ones should be done while taking into account the team's preferences, needs, and existing workflows. By embracing this shift, teams can work more efficiently, collaboratively, and adapt to the changing dynamics of the workplace.

How to 301 Redirect to a new domain with AWS S3 & CloudFront

Ryan Fitzgerald — Thu, 09 Mar 2023 00:11:49 +0000

Motivation

Recently I made the decision to rebrand a side project of mine which involved changing the domain name from ChromeExtensionKit.com to ExtensionKit.io. At it's core, it wasn't a difficult move, however the old domain had reasonably good SEO and search ranking so I wanted to ensure that I maintained that as much as possible through a permanent 301 redirect of the old domain. The main challenge was that the domain pointed to a single static site so I didn't have easy access to a server where I could add a simple .htaccess.

I looked at a couple of options such as spinning up a quick Lambda to perform the 301 redirect and even looked at handling the redirection at the DNS level, however I ultimately settled on the AWS S3 and CloudFront approach as it was both the easiest and cheapest option. This blog post will go over how to setup a 301 permanent redirect from an old domain to a new domain with HTTPS support and 1:1 mapping of paths (for example, oldsite.com/page1 redirects to newsite.com/page1).

For this walkthrough, we will assume that we are moving a fake domain oldsite.com to a new (also fake) domain newsite.com. This will also assume that the new domain (newsite.com in this example) is already setup and supports HTTPS traffic.

1. Configuring Route53

The first step is to create a new Hosted Zone in AWS Route53. To get started, login to the AWS console and head over to Route53. Once there, simply add in your old domain that you'll be moving into the domain name field. All other options can be kept as the defaults.

Next, go to where you have your old domain hosted and update it to point to the nameservers provided by AWS. We will come back to Route53 to connect AWS resources later.

2. Creating a certificate

After pointing your old domain to AWS, you'll need to ensure it utilizes HTTPS. This can be accomplished easily within AWS by heading over to Certificate Manager. Once there, click Request a certificate and ensure public certificate is selected. After that, enter your domain you just added in step 1 under the Fully Qualified Domain Name field.

After creating, you will see that the domain requires validation to prove that you own it. Under the Domains section, click the Create records in Route 53 button which will open Route53 once again where you can add the required txt record that proves ownership. Once that is complete, you should see status of Issued on the certificate page after a bit of time.

3. Setting up S3

Next we will setup the redirecting mechanism. This is accomplished via S3 in website hosting mode. Head over to S3 and create a new bucket with the name of your old domain (or some other unique name) and ensure Block all public access is unchecked.

Once created, navigate into the bucket and open the Properties tab. At the bottom, click Edit under Static website hosting. Once there, enable Static website hosting and choose Redirect requests for an object as the hosting type. Finally, enter your new domain as the host name and choose https as the protocol. This should look like the following:

After creating it, copy down the Bucket website endpoint as you'll need this later when setting up CloudFront. It should be in the form of http://{bucketname}.s3-website-{region}.amazonaws.com.

4. Setting up CloudFront

Now that we have the old domain setup and the redirect to the new domain in place, we need to tie it together and support HTTPS traffic via CloudFront (as the current redirect will not support HTTPS redirection). Head over to CloudFront and click Create distribution to create a new distribution.

Under the Origin section, enter your bucket website endpoint URL you copied in Step 3 above and put that into the Origin domain. It is important that you paste in the S3 website endpoint and not select the bucket itself or it will not work as expected. Every other setting in this section can be left as the default.

Next, under the Settings section, either keep the Price class as the default or change to another to slightly reduce cost (for example, NA and Europe). After that, click Add item under Alternate domain name (CNAME) and add your old domain (in this case, we will use oldsite.com). Finally, under the Custom SSL certificate, find and select the certificate created in Step 2 (in should appear in the list if done correctly). Every other setting in this section can be left as the default.

Finally, click Create distribution to finish the process and wait for the distribution status to change to Enabled.

5. Tying it all together

The final step in the process is to head back over to Route53 and tie everything together. Open up Route53 and head into your Hosted Zone created in Step 1. Once there, click Create Record and choose A as the Record type and enable the Alias checkbox. From there, select Alias to CloudFront distribution in the first dropdown and select the distribution you just created in the second dropdown. This should look something like:

Once complete, give it some time to fully propagate and you should be ready to verify. This final step effectively linked the domain to CloudFront, which behind the scenes uses the certificate we created to enable HTTPS and pushes traffic to our S3 bucket which in turn redirects to the new domain.

6. Verifying the redirect

After completing steps 1-5, you are ready to verify the redirect is working as intended. It is worth noting that if you don't see the changes active immediately, you may need to give it a bit of time to propagate fully. Once you've given it enough time, you can either visit the old url and enure you're automatically redirected to the new one, or you can perform a curl command that'll also return the 301 status. To perform this, simply enter the following into your terminal:

curl -I https://oldsite.com

After running, you should see something similar to the following:

HTTP/2 301
content-length: 0
location: https://newsite.com
date: Fri, 03 Mar 2023 21:48:18 GMT
server: AmazonS3
x-cache: Hit from cloudfront
via: 1.1 someid.cloudfront.net (CloudFront)
x-amz-cf-pop: some-cf-pop
x-amz-cf-id: some-cf-id
age: 10000

You should notice at this point that the status is 301 signifying the permanent redirect and the location is your new domain.

One final step that is beneficial when performing a domain move is to notify Google so you don't lose SEO rankings. For more information on their Change of Address Tool, click here.

TL;DR

You can setup a permanent 301 Redirect from an old domain to a new one easily and cost effectively using AWS. Make sure your new domain is active and supports HTTPS, then perform the following:

Add your old domain Route53
Create a certificate for the old domain using Certificate Manager
Create an S3 bucket in website hosting mode and redirect to your new domain
Create a CloudFront distribution for the old domain using the cert from step 2 to support HTTPS and link to S3 website endpoint created in step 3
Add an Alias record in Route53 for the old domain that points to the CloudFront distribution in step 4

At a high level, this strategy uses S3 website hosting mode to redirect to the new domain by creating a CloudFront distribution in front of the old domain (to allow for HTTPS redirects) pointing to the S3 bucket.

Understanding the useEffect Hook in React

Ryan Fitzgerald — Tue, 27 Oct 2020 14:20:09 +0000

Since their release in React 16.8, hooks have quickly become a powerful tool in any React developers toolbox. One of the default hooks I find myself using all the time is useEffect, which allows you to perform side effects in your functional components.

Although useEffect is useful for managing side effects in React apps (data fetching, manual DOM manipulation, and so on), it can often be a source of confusion for those who haven't run into it before, and more importantly, it can negatively impact performance of your app if used incorrectly.

The most important thing to understand with the useEffect hook is that it attempts to runs after every single render of the component (including initial render) it is defined in. With that said, you can customize how often the useEffect logic runs in your component fairly easily. It's also worth noting that useEffect only gets run after the browser has painted, meaning it doesn't block the browser from updating.

In the next couple sections, I'll discuss the various possibilities for running useEffect as well as provide some examples and compare it to the class lifecycle methods were appropriate.

Run Every Render

By default, useEffect will run on initial render as well as every future render (update) of your component. This basic usage looks like this:

useEffect(() => {
  console.log('I run on every render');
});

To further clarify this, let's take an example from the React docs:

const Example = () => {
  const [count, setCount] = useState(0);

  useEffect(() => {
    document.title = `You clicked ${count} times`;
  });

  return (
    <div>
      <p>Clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>Click me</button>
    </div>
  );
};

This is a basic counter component that increments the counter (using state) and changes the page title (side effect) every time the button is clicked.

So how does this work? When the button is clicked, the count state variable is updated. As a result of state being updated, the component re-renders and then the useEffect is triggered, which in turn updates the document (page) title.

Although not fully the same, this usage would be similar to using a combination of componentDidMount (to cover the initial render) and componentDidUpdate (to cover future updates) in class components.

Run Once

Now that we've seen the default case, how can we customize the useEffect hook to run only once (i.e. on initial render)? There is a second and optional argument of useEffect, which is a dependency array. If we want to run it only once, we can define it as follows:

useEffect(() => {
  console.log('I run once, on initial render');
}, []);

When your component re-renders, useEffect will first check the dependency array provided to it and only run if one of the dependencies have changed. In this case, we provide an empty dependency array, so nothing will ever change, hence only being run once on initial render.

Common use cases for only running on initial render may be to fetch data or to change the page title. Once again, this can be compared to componentDidMount.

Run on Dependency Change

Now that we know useEffect has an optional second argument, we can use that to customize it to run only on dependency change (such as state or props, for example). This would look something like this:

useEffect(() => {
  console.log('I run every time myVar changes');
}, [myVar]);

In the above example, the useEffect logic would be run on the initial render, and then every subsequent render where myVar has changed in value. If myVar hasn't changed between renders, it won't run.

To clarify further, let's take the original counter example and convert it to use the dependency array:

const Example = () => {
  const [count, setCount] = useState(0);

  useEffect(() => {
    document.title = `You clicked ${count} times`;
  }, [count]);

  return (
    <div>
      <p>Clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>Click me</button>
    </div>
  );
};

Now every time the count is incremented and the component is re-rendered, it will change the document title, similar to above.

You may be thinking, why bother providing the dependency array if the first example worked just fine? In this case, there isn't much difference and either option works. However, as soon as you add an additional piece of code to the original example (without the dependency array) that causes re-renders as well (such as additional state), you run the risk of the useEffect block running more than it needs to, since it runs on every render. With that in mind, it's typically good practice to provide the dependency array unless you have a specific reason not to.

Run on Clean Up

The final case I'll be covering is the clean up case. This version is typically used when subscribing to something, such as sockets, as you'll also want to unsubscribe when the component is no longer mounted. This pattern would look something like:

useEffect(() => {
  console.log('I run on every render');

  return () => {
    console.log('I run on clean up');
  };
});

In the above snippet, we return a function from the useEffect which tells it what to run on clean up. When clean up is triggered (i.e. component unmounts), the code inside would get triggered. For example, we may want our component to subscribe to sockets on render and then unsubscribe to the sockets when that component unmounts as they are no longer needed.

Another point worth making here is that you can still use the dependency array discussed above in the same way as this will not impact how that works.

Using More Than Once

Similar to other hooks such as useState, you can also use useEffect multiple times in one component.

For example, let's take the following:

const Example = ({ myProp }) => {
  useEffect(() => {
    // Do something on initial render only, like changing document title
  }, []);

  useEffect(() => {
    // Do something every time a prop changes, like fetch some additional data
  }, [myProp]);

  // ... Rest of the component
};

In the above component, it would run the first useEffect only on initial render, which may be responsible for setting the page title, for example. The second useEffect may be used to fetch data based on a prop and would also be run on initial render, but it will also get run every time the component re-renders and myProp has changed.

This pattern is helpful if you have side effects that happen at different times and in different ways within your component.

Conclusion

I hope you found this high-level overview of the useEffect hook helpful! If you have any questions or feedback, feel free to reach out on Twitter or comment below.

If you'd like to go a little deeper on the useEffect hook and how it works under the hood, the Official React docs page is an excellent resource.

Error Tracking in Chrome Extensions

Ryan Fitzgerald — Thu, 22 Oct 2020 01:01:59 +0000

So you've built a Chrome Extension and published it to the store, but how do you ensure it's running smoothly for your users? Unlike a normal web service, it's a bit tougher to figure out when things go wrong within a Chrome Extension and even more frustrating to try and recreate the issue while attempting to debug it. It's important to try and figure out a way to track errors that pop up before they appear in the form of a bad review on your extension.

Fortunately, there are a number of error logging services available that can be added to your Chrome Extension with just a little bit of work.

Choosing a Service

The first step is figuring out which service you'd like to use. There are an endless amount of error monitoring and reporting tools out there, so I'll list a few you can look into in order to see which fits your needs. Some of these include:

For the purpose of this walkthrough, I'm going to go ahead and choose Sentry. I've used the service many times in the past and love how easy it is to get setup, plus they have a pretty decent free plan if you're just getting started. If you'd like to follow along using Sentry, just head over to their site and sign up for an account, if not, feel free to use your own tool and simply change it to your tool's config when we add the setup details.

Getting Started

To get started, I'm going to head into the Sentry Dashboard and create a new Project. You'll find the button in the top right of your Projects page.

Next, I'm going to choose Browser Javascript as the project type. If your extension uses NPM or Yarn (i.e. you are building with React, etc), then you should pick simply Javascript as it will walk you through installing the package via NPM. Most providers should also have a similar basic JavaScript variation. Once you create your project, you will most likely be provided with some instructions to add a script similar to this:

<script
  src="https://browser.sentry-cdn.com/5.23.0/bundle.min.js"
  integrity="sha384-5yYHk2XjpqhbWfLwJrxsdolnhl+HfgEnD1UhVzAs6Kd2fx+ZoD0wBFjd65mWgZOG"
  crossorigin="anonymous"
></script>

And the corresponding init function looking something like:

Sentry.init({ dsn: 'my-sentry-dsn-here' });

There are 2 ways we can actually add this to our extension. The first, and easiest way, is if your extension has it's own HTML page (i.e. new tab, popup, etc) which allows you to simply add the above script tag and to init the script via your own JS file. The second option is if your extension runs in the background, in which case you would need to dynamically inject the above script tag and init it afterwards, most likely via background scripts.

For the sake of this simple walkthrough, we'll go over the first method in the next section.

Adding To Your Extension

Let's start by creating a new example extension with 3 files: manifest.json, index.html, and scripts.js.

manifest.json: the extension manifest file
index.html: the HTML for our sample extension
scripts.js: this is the script we load into our page and other than initializing Sentry, it would also include your overall extension logic most likely

The manifest.json file will look like:

{
  "manifest_version": 2,
  "name": "Error Tracking Example",
  "version": "1.0.0",
  "browser_action": {
    "default_popup": "index.html",
    "default_title": "Open Popup"
  },
  "content_security_policy": "script-src 'self' https://browser.sentry-cdn.com; object-src 'self'"
}

It's important to note that the content_security_policy portion is what allows our Sentry script to load and communicate cross-origin (i.e. send the error back). By default, Chrome Extensions disable all cross-origin requests to mitigate potential cross-site scripting attacks. In this case, we are letting Chrome know that we want to load from the specific Sentry origin. For more information, click here.

The index.html file will look like:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>Error Tracking Example</title>
    <link rel="stylesheet" href="css/index.css" />
  </head>
  <body>
    <p>Hello World!</p>
    <script
      src="https://browser.sentry-cdn.com/5.23.0/bundle.min.js"
      integrity="sha384-5yYHk2XjpqhbWfLwJrxsdolnhl+HfgEnD1UhVzAs6Kd2fx+ZoD0wBFjd65mWgZOG"
      crossorigin="anonymous"
    ></script>
    <script src="scripts.js"></script>
  </body>
</html>

And finally, the scripts.js file will look like (init for Sentry and our extension logic, which is just an error in this example):

// Init sentry
Sentry.init({ dsn: 'my-dsn-here' });

// Call a random, undefined function. This will cause an error
myUndefinedFunction();

Testing It Out

Now that we have our test extension setup, navigate over to chrome://extensions/ and make sure you have Developer Mode enabled.

Next, load the unpacked extension and click the extension icon in the browser bar.

If you navigate back to chrome://extensions/, you should see errors have popped up for the extension locally. If we didn't have error monitoring, a user could run into this situation and we would have no idea that it happened nor could we reproduce it (unless they provided us with necessary information).

This isn't great because this may result in some negative reviews on the Web Store before we can even attempt to fix it. Fortunately, error handling has us covered here.

In order to see it in action, we can navigate back to our Sentry Dashboard and see if that error has been captured and sent to us there. If all goes well, you should see something similar to the following:

If you were to click on the issue, you would be presented with more information such as where the error happened, the user's Chrome version, OS type, and more, which can provide you with context to help solve the issue.

Final Notes

As mentioned briefly, this example assumes your extension has an HTML page, however not all extensions will work like this. In the event that your extension doesn't have an HTML page to output, or if you also need error tracking outside of the scripts referenced in the HTML page, you would need to include Background Scripts that inject the script tag and init Sentry. This would take 2 parts: updating the manifest to reference your new Background Script and adding the initialization into the Background Script itself.

Another point worth mentioning is the inclusion of the Sentry library via the CDN. This can be avoided if you download the source code for your error tracking tool and bundle that with your extension, however this can come with its own challenges, such as having to ensure that file is kept up to date as new versions are released (which may require you to push an update to the web store for your extension with the latest Sentry code).

I hope this provided you with a basic introduction to error handling in the Chrome Extension environment so you can be confident in the future that your extensions are running smoothly for all users.

If you have any questions, feel free to reach out to me on Twitter. Also, I created ChromeExtensionKit, which is a kit that helps simplify the Chrome extension development and growth process, so feel free to check it out!

Tailwind + React: Setup and Design Patterns

Ryan Fitzgerald — Tue, 20 Oct 2020 02:42:39 +0000

You can find all source code for this post in a starter template here.

Feel free to reach out on Twitter any time with questions as well.

What is Tailwind?

You've probably heard of Tailwind by now, but if you haven't, it is essentially a utility-first CSS framework and is much less opinionated compared to other CSS frameworks like Bootstrap and Foundation. According to tailwindcss.com, it is described as:

A highly customizable, low-level CSS framework that gives you all of the building blocks you need to build bespoke designs without any annoying opinionated styles you have to fight to override.

In my opinion, this makes Tailwind a great option to use for your projects. You get the benefits of rapid development, without the opinionated styles that you ultimately override anyway.

So what if we want to use Tailwind with React, is it as simple as just including a style sheet? Not exactly. Because of how Tailwind is built and some of the optimizations they have in place (i.e. purging unused CSS), there are a couple extra steps to properly set it up in a React project.

Getting the Project Setup

To get started, either jump into your own React project or start up a new one with npx create-react-app tailwind-react-app.

Installing Dependencies

Next, let's install a couple of dependencies via npm i @fullhuman/postcss-purgecss postcss-cli tailwindcss --save-dev.

A brief explanation of each dependency:

fullhuman/postcss-purgecss - used to purge unused CSS to create the smallest final CSS file possible. If you don't purge unused CSS, tailwind is actually over 2MB uncompressed.
postcss-cli - Tailwind is a PostCSS plugin. You don't need to use PostCSS as the preprocessor, but in this case we will in order to keep things simple.
tailwindcss - the Tailwind library and utilities

Create Config Files

Now that we have our dependencies installed, we need to create a couple config files.

First, create your Tailwind config by running npx tailwind init in the project root. You can choose to update some of the Tailwind config here if you wish.

Next, create your PostCSS config by creating a postcss.config.js file in the project root and adding the following content:

const purgecss = require('@fullhuman/postcss-purgecss')({
  content: ['./src/**/*.js', './src/**/*.jsx', './public/**/*.html'],
  defaultExtractor: (content) => content.match(/[A-Za-z0-9-_:/]+/g) || [],
});

module.exports = {
  plugins: [
    require('tailwindcss'),
    ...(process.env.NODE_ENV === 'production' ? [purgecss] : []),
  ],
};

In the first portion, we require and setup purgecss. This requires two pieces. The first is the list of purgeable files which are js, jsx, and html (you can also add .ts and .tsx). The HTML is required so the base styles (e.g. body, html, etc) don't get purged.

The second portion is used to define the extractor function (i.e. rules for which content to keep). PurgeCSS is naive by nature, meaning it will look for content that matches that Regex in the file types listed above. This is important to know and will be revisited when we discuss patterns below.

Importing Tailwind CSS

Now that we have our dependencies installed and our config files setup, we can actually add the Tailwind CSS file to our app. To begin, create a tailwind.css file in the src/ folder with the following Tailwind directives:

@tailwind base;
@tailwind components;
@tailwind utilities;

This will pull in and compile the styles for us automatically when we build our Tailwind output. It's also useful to note that this file is where we could add our own Tailwind custom utilities if we wanted. For more information on adding new utilities, click here.

Finally, let's import the output file (which we will create via the build scripts in the next section) to our app.js so it is available globally throughout our app.

import './tailwind.output.css';

You may need to change the path if your app.js isn't directly in the root of the /src folder, as that is where this will output by default.

Setting Up Build Scripts

The last step to get Tailwind working is to create a couple quick build scripts to ensure that the output file gets built. Let's add the following to our scripts section in package.json:

"tailwind:build": "NODE_ENV=production postcss src/tailwind.css -o src/tailwind.output.css",
"tailwind:dev": "postcss src/tailwind.css -o src/tailwind.output.css",
"prestart": "npm run tailwind:dev",
"prebuild": "npm run tailwind:build",

There are two separate Tailwind scripts we created. The first :build one is for production builds (i.e. run the PurgeCSS we defined above), whereas the second one is a dev build which keeps the full Tailwind CSS since we want to access all the styles as we're developing.

The next part is the prestart where we run the dev build prior to staring up the React development server. You could take it a step further and add a watch script that checks for changes to tailwind.css, but I've found that additions / changes to this file are pretty rare, so I simply restart the dev server if this comes up.

Finally, the last part is the prebuild script which runs the production (purged) Tailwind build which will result in a CSS file that only contains styles we've actually used in our app.

That's it! You should now be up and running with Tailwind in your React app. If you're looking to take it a step further, in the next section I'll go over some design patterns and common gotchas when dealing with Tailwind in React.

Design Patterns

Now that we have Tailwind running within our app, when we can discuss some design patterns that make it easy to work with in React components.

What Not To Do

Before jumping into some patterns, I think it's worth mentioning what not to do. How you decide to use Tailwind in your app is ultimately up to your preference, but there is one common mistake that can quickly get you into some trouble and it relates to the purging of the unused CSS as I mentioned above.

Let's look at an example to illustrate the issue. Assume we have a basic input component as follows:

<input className="border-2 border-gray-300 p-2" type="text" />

Now, let's say we want to conditionally change the border to red if there is an error somewhere. If we have an error state / prop variable, we may be tempted to do something like:

<input
  className={`border-2 border-${error ? 'red-500' : 'gray-300'} p-2`}
  type="text"
/>

At first glance, this looks correct. In fact, it would render the correct classes and work just fine in development. However, once you build the production version of your app, you would notice these styles are missing, but why is that? As mentioned earlier, PurgeCSS runs against our production build to create the smallest Tailwind CSS file possible. It simply looks at the file types you provided and tries to find content matching the Regex. In this case, when it checks this component file, it won't match on border-red-500 or border-gray-300 because they are built dynamically. Instead, it will come across red-500 and gray-300 and not work as intended.

So how do we avoid this? The easiest way is to always ensure when writing Tailwind classes in your code, the full class name is there and isn't built dynamically. Therefore, using the above example, we get:

<input
  className={`border-2 ${error ? 'border-red-500' : 'border-gray-300'} p-2`}
  type="text"
/>

Now when PurgeCSS runs against this file, it will keep border-red-500 and border-gray-300, as it should.

Let's take a look at some basic Tailwind patterns we can use in our app now that we know what not to do.

Basic Pattern

A pattern I've been using for a little while now is one that involves defining all of your classes above the component in an object with strings for each element.

For example, here is a basic component:

Using the above pattern, the component code would look like:

const classes = {
  wrapper: 'border-2 m-16 p-16',
  title: 'text-gray-800 text-xl text-center font-bold',
};

const BasicComponent = () => {
  return (
    <div className={classes.wrapper}>
      <h1 className={classes.title}>Basic Component</h1>
    </div>
  );
};

This basic pattern has a couple nice benefits:

It keeps the component definition clean, especially if there are a number of elements or if class names get long
It makes it easy to reuse classes in multiple places. Also, if you need to change styles, you only do it in one place in the component.
All classes are fully defined in the file, so there are no issues with PurgeCSS
You get a nice overview of all styles for your component in one neat place

With that said, what do we do when we get more advanced components that need to change as state or props change in our app? Let's take a look at a more advanced pattern that expands on this.

Advanced Pattern

Now that we have a basic pattern involving the definition of all our classes above our component, we can take it a step further when we start to have more dynamic components.

For example, here is a more dynamic component:

In the above screenshot, both the button and the subtitle text change when the button is clicked on. Let's look at the code for this component:

const classes = {
  wrapper: 'border-2 m-16 p-16 text-center',
  title: 'text-gray-800 text-xl font-bold',
  description: (active) =>
    `my-6 ${active ? 'text-red-900 font-medium' : 'text-gray-800'}`,
  button: 'py-2 px-4 bg-gray-100 border-2 focus:outline-none',
  buttonActive: 'bg-gray-400',
};

const AdvancedComponent = () => {
  const [active, setActive] = useState(false);

  return (
    <div className={classes.wrapper}>
      <h1 className={classes.title}>Advanced Component</h1>
      <p className={classes.description(active)}>
        I change based on the button click state.
      </p>
      <button
        className={clsx([classes.button, active && classes.buttonActive])}
        onClick={() => setActive((prevState) => !prevState)}
      >
        Click Me
      </button>
    </div>
  );
};

The first thing to notice is the description class. Unlike the others, this one is a function that takes in a parameter (or multiple) and outputs a slightly different class (text color and font weight in this case) string as a result. This allows you to maintain the benefits of the basic design pattern, but also add in a conditional aspect as well. It's also import to note, the classes are still fully defined as well so PurgeCSS will still have no issues.

Another method of creating dynamic classes while maintaining the basic pattern is what was done with the button and buttonActive classes. In this case, the clsx module was used to dynamically add classes based on conditions. The classes.button class was added without conditions (the base styles), however classes.buttonActive is only added if active is true. This method also works well when you have a number of conditionally added classes to an element or if your classes are just getting a little out-of-hand and you want to break them down a bit. Once again, PurgeCSS will work fine with this method as the underlying classes are fully defined.

Conclusion

I hope this helped get you up and running with Tailwind on your React app and gives you some inspiration on how you can use it within your components in a way that makes it easier to work with.

If you have any questions, suggestions, or run into any issues, feel free to reach out on Twitter.

I open-sourced my portfolio + blog template built with Gatsby & Tailwind

Ryan Fitzgerald — Sun, 18 Oct 2020 01:59:29 +0000

Hey everyone! I recently open-sourced Devfolio, which is a personal portfolio + blog template I built with GatsbyJS and TailwindCSS.

I wanted to create something that was completely production-ready out of the box (you just edit one config file and deploy), but also easy to customize and extend if you wanted to take it further. Also, because it's built with Gatsby, the final result is fairly fast.

I'm currently using a slightly customized version for my own personal site as well, if you wanted to see another example of it.

Hopefully some of you find it useful for your own purposes and if anyone has any suggestions for additions, I'd love to hear them! Also, if you need any help, feel free to reach out on Twitter.