Forem: Joel Rainwater

Web Developer Tools Fundamentals

Joel Rainwater — Sat, 02 Jul 2022 07:59:29 +0000

You know how to write code... now what?

A common challenge new developers run into is making the transition from writing code in a closed environment, such as a tutorial or course, to building a real project. Suddenly there's a whole new world of tools that are mentioned but not explained.

Perhaps you are trying to set up your first development project on your local and don't know where to start. Or maybe you're reading a tutorial or some documentation and it says "Prerequisite: npm/yarn, webpack, hadron collider, etc...". Ok, maybe not that last one, but you get the idea.

WTF is npm and how do I use it? How do I set up a local environment, deploy to a server, or share my code with other developers?

Introduction

I am Joel, a self-taught web developer for over 10 years. As a self-taught developer, and a mentor for new developers, I have both experienced these challenges and hear these questions often from those who are learning to code.

I've noticed that there are a lot of code adjacent things that are not well covered, or just expected or assumed knowledge in a lot of documentation, tutorials, and courses.

What to expect

I will be writing a series of articles in an attempt to break down these popular tools and processes in an understandable way.

I won't be going into tedious depth, this is intended for beginners to get a grasp on the basics. If you'd like to learn something more in-depth let me know and I'll do what I can in a separate article.

Subjects covered

Below are the subjects I intend to cover. Note - some subjects will be specific to a particular ecosystem (e.g. npm for JavaScript projects) while others will be more widely applicable (e.g. git for any code project).

git (and the difference between git and GitHub)
npm/yarn
CI/CD
webpack + babel
Browser vs Client side code
HTTP calls (APIs, database queries, etc...)
Servers / hosting
CSS preprocessors
JavaScript modules (ESM, CJS) and import/export

If there are any subjects you'd like me to cover please post a comment below to let me know!

Follow along

I'll be writing and posting these over time and including them in a series so that this article, and all articles in the series, will update with links to each new article once published.

Subscribe to my posts here if you'd like to be notified when a new article drops. And let me know your thoughts!

See you soon...

Using Mixpanel via proxy with Next.js rewrites

Joel Rainwater — Sat, 26 Mar 2022 19:22:36 +0000

Quick Overview

Mixpanel has great documentation for setting up your project in many different languages, including JavaScript. They also provide docs and examples for implenting tracking with a proxy. Setting up Mixpanel through a proxy is useful to bypass ad and tracking blockers, and is a nice way to keep all client requests through your domain.

I didn't see any great resources out there for setting up Mixpanel specifically in Next.js using their built-in Rewrites feature to accomplish the same goal as setting up a proxy. Using rewrites, I was able to keep all Mixpanel requests going through the same domain as my website/app, and didn't need to deal with configuring Nginx myself (I'm hosting on Vercel, so I don't normally have to touch webserver config).

This is how I implemented that setup.

Step 1: Install Mixpanel's JS SDK

We are going to use Mixpanel's JS SDK mixpanel-browser. You can install it with npm/yarn as follows.

# npm
npm install --save mixpanel-browser
# yarn
yarn add mixpanel-browser

If you're using TypeScript, you can also install @types/mixpanel-browser to have typings.

Step 2: Create Mixpanel wrapper function

Note - This post is to explain the setup for using Next rewrites. I used this article as a guide for creating a basic Mixpanel wrapper function.

Create a file called mixpanel.{ts|js} wherever it makes sense in your project. We will be defining an object which will be imported and used anywhere you plan to implement Mixpanel tracking.

// Remove { Dict, Query } if not using TypeScript
import mixpanel, { Dict, Query } from "mixpanel-browser";

const isProd = process.env.NODE_ENV === "production";

mixpanel.init("YOUR_MIXPANEL_TOKEN", {
  // Use your project's URL, adding a slug for all Mixpanel requests
  api_host: "https://yourdomain.com/mp",
});

export const Mixpanel = {
  identify: (id: string) => {
    mixpanel.identify(id);
  },
  alias: (id: string) => {
    mixpanel.alias(id);
  },
  track: (name: string, props?: Dict) => {
    mixpanel.track(name, props);
  },
  track_links: (query: Query, name: string) => {
    mixpanel.track_links(query, name, {
      referrer: document.referrer,
    });
  },
  people: {
    set: (props: Dict) => {
      mixpanel.people.set(props);
    },
  },
};

First we import the mixpanel-browser library.

When in initialize it, we specify our own api_host. This is where we tell Mixpanel to use our URL instead of theirs. This url should be the same as your Next.js project's URL, with a specific slug which will be dedicated to only Mixpanel requests (e.g. /mp). You can make this whatever you want it to be, so long as it is not used anywhere else in your project.

Step 3: Add rewrites

Now we need to tell Next to handle the rewrites for the URL we just provided to Mixpanel.

In next.config.js add the following (yours might have additional configs already, the rewrites is what we care about).

/** @type {import('next').NextConfig} */
module.exports = {
  async rewrites() {
    return [
      {
        source: "/mp/lib.min.js",
        destination: "https://cdn.mxpnl.com/libs/mixpanel-2-latest.min.js",
      },
      {
        source: "/mp/lib.js",
        destination: "https://cdn.mxpnl.com/libs/mixpanel-2-latest.js",
      },
      {
        source: "/mp/decide",
        destination: "https://decide.mixpanel.com/decide",
      },
      {
        source: "/mp/:slug",
        // use "api-eu.mixpanel.com" if you need to use EU servers
        destination: "https://api.mixpanel.com/:slug",
      },
    ];
  },
};

This tells Next, when a request is made to each of these endpoints, it will perform a rewrite to the destination URL. You can find more details about these rewrites in Next's documentation.

Step 4: Track things

Now you can use your Mixpanel object throughout your Next project. Import it using import { Mixpanel } from './mixpanel';

Then use it to track events, link clicks, and anything else useful. (These are just examples, not indicative of useful events to track).


import { useEffect } from "react";
import Link from "next/link";
import { Mixpanel } from "./path/to/mixpanel";

const PageName = () => {
  useEffect(() => {
    Mixpanel.track("Loaded PageName");
    Mixpanel.track_links("#nav a", "Nav link clicked");
  }, []);

  const handleButtonClick = () => {
    Mixpanel.track("Button clicked");
    alert("Button clicked!");
  };

  return (
    <div className="container">
      <div id="nav">
        <Link href="/dashboard">
          <a>Home</a>
        </Link>
        <Link href="/about">
          <a>About</a>
        </Link>
        <Link href="/pricing">
          <a>Pricing</a>
        </Link>
      </div>

      <button onClick={handleButtonClick}>Click me!</button>
    </div>
  );
};

export default PageName;

Wrapping up

There you have it. All requests for Mixpanel should now be going through your app's domain, effectively working as a proxy using Next's built-in Rewrites capabilities.

Let me know if this worked for you, or if you have suggestions for a better approach in the comments!

Building a headless eCommerce shop with Magento and Vue

Joel Rainwater — Fri, 28 Jan 2022 20:14:52 +0000

How it started

Having worked in Magento for years, I am all too familiar with the challenges that come with using it, especially when it comes to performance. However, I do enjoy the extensibility of Magento, and the massive community that comes with it.

For years, Netatmo's online shop was running on Magento 1, and it "worked" sufficiently for the time. Between the years of technical debt as a result of numerous developers and agencies working on it, and the upcoming EOL for Magento 1 support, it was quickly becoming obvious that an upgrade was due for the shop.

Deciding on the stack

One of the most challenging parts of any project - what technology stack do we want to use!?

We decided to stick with Magento, moving to v2, for a number of reasons. The migration from M1 to M2 should be easier than from Magento to some other platform. I have worked with Magento 1 and 2 for a number of years, and migrated multiple sites from M1 > M2. Being the technical lead of the shop, it made sense for us to use Magento 2 as it would mean less learning time on my part, and an easier onboarding process for other devs. And finally, we couldn't find another eCommerce solution that provided the extensibility of Magento, and allowed us to host it internally due to our very serious approach to security.

Ok, Magento 2 it is. But, what about the frontend? Magento is notoriously slow, and seems to be getting worse in v2. So what about separating the frontend? There are plenty of choices with all of the powerful JavaScript frameworks and libraries available today.

Magento PWA Studio was in development at the time, and not ready to use in production. Additionally, it is built in React, and the preferred technology for most of our frontend team is Vue. So, we shopped around.

Enter Vue Storefront.

With Vue Storefront (VSF), we could build a completely separate frontend as a PWA, using tech like ElasticSearch, Redis, and localStorage to provide a significant boost in performance. This meant a number of important things.

Limiting communication with Magento

Because most of our data would be stored in ElasticSearch, we could limit API calls to Magento to only necessary moments - when we need live data (checking current stock on checkout) or when an action needs to be stored or calculated by Magento (i.e. placing an order). This means even if Magento is slower than we'd like, it only impacts the user's experience at specific points, which we can control. Of course we still took necessary measures to optimize Magento's performance as best as we could for those moments.

Locking down Magento

The client never talks directly to Magento, but instead goes through the Vue Storefront API. This means, we can completely lock down our Magento instance from the outside world, only allowing communication to and from specific sources which we meticulously control. Of course we still need to follow security best-practices and keep everything up-to-date, but this low-level restriction provides an additional level of protection from inevitable vulnerabilities in a PHP-based framework like Magento.

Frontend freedom

We would no longer be locked-in to the Magento frontend. This is great because we can share the frontend development across our team without the need to teach others an entirely new templating framework. If you've worked in a Magento theme, you know this is huge - it's not exactly a simple theming system. This meant our Vue developers come be onboarded fairly painlessly, and we could focus on what's important - building it.

Improving deployments

Separation of concerns means easier iteration, and less downtime. With Magento being used as headless, our frontend and backend can have separate projects with their own repos, pipelines, etc... This means we can deploy back-end and frontend changes independently without impacting the full stack.

Also, since the frontend is a PWA, when we do deploy to Magento the frontend won't be completely down. Magento has to run a lot of things during deployment, and only some of it can be handled in the pipeline before taking it down for Maintenance. With VSF, we can allow the frontend to run almost as usual - except for those moments we need to communicate with Magento, which can either be queued or handled as if the user is offline. And because deploying a Vue app is much faster than a full Magento deployment, we can iterate the frontend quickly with virtually no downtime for the users, all without impacting the Magento administration teams.

Alright, so it's decided. Vue Storefront + Magento 2 will be our stack.

Technical overview

I'm not going to give away too much for the sake of security, but here are some details about how Vue Storefront works in general and how we implemented it specifically.

Let's work our way from back to front.

Magento

This layer doesn't need too much detail. It's a pretty standard Magento 2 setup for the most part. The key difference is that our Magento instance is not publicly accessibly. Here are a few benefits and hurdles that this introduced.

Better access control

We have two ways to access Magento - the API is access at a specific domain, while the back-office is accessed from a different domain. This allows us to maintain a separate list of allowed sources for the API integrations vs administrators. This is on top of the access-control list (ACL) management provided by Magento. Now we've got three layers of managed permissions to get through - Firewall, web server allowances managed per route, and Magento ACL (for both administrators and API users).

Backend integrations are challenging

Due to these restrictions, we have some potential hurdles to overcome with any new integration we introduce into Magento.

The 3rd party's system must provide a list of static IPs, or a way for us to generate a list from their IP pool. Not all systems can provide this which has become a blocking point on a few features. At this point we must either find a new vendor, request the vendor provide us an alternative, or compromise on some workaround between the two of us. It can be frustrating and time-consuming, but in the end I still believe it's worth it.

Magento URLs are always wrong

Magento comes with some built-in code for generating URLs for products, categories, pages, etc... However, these are inherently wrong for us now because it uses the Magento URL, and not our frontend. This can be a concern with emails sent from Magento for example, or with any 3rd party module that might export data. This isn't a concern on the frontend as Vue Storefront handles this, but when it comes to Magento-only functionality / integrations, this can be an issue.

For now, the only solution I have been able to come up with is using well-placed plugins to generate frontend URLs when a frontend URL is trying to be generated by Magento. To do this I added some configuration fields in Magento to provide things like the frontend base URL, and some path details. We also pull some final data from ElasticSearch (more on that later) to use the same indexed data as VSF.

I have hopes that Magento might introduce a similar type of feature one day, especially with the new PWA Studio they provide and the increasing popularity of the headless approach.

ElasticSearch

The team at Vue Storefront provides a Magento 2 module which uses Magento's native indexing functionality to index all pertinent data to ElasticSearch (ES) in a format which can be utilized by VSF. Because it hooks into the native indexing of M2, data can be automatically reindexed on Save if you wish to configure it to do so.

Now, I know Magento 2 also comes with ES, and they can use the same instance I believe, but VSF requires the data to be sent in a uniform way it can read. They have a "platform agnostic" approach, so the data on the front needs to be as pure as possible, removing back-end platform flavor where possible. The module seems well-built, and even has a CLI command for reindexing manually with a few options. We have also created a few of our own modules which extend the VsBridge module to index some custom data points to ES.

Thanks to this module, the static data now sits in ES, allowing our frontend to quickly fetch minimal data as needed without putting load on Magento.

Vue Storefront API

Vue Storefront comes with its own API which serves as a sort of middleware. It is written in NodeJS, which is nice because it means another technology isn't introduced into our stack. JavaScript developers can work on this layer as needed and feel right at home.

This API layer is what the frontend uses for all of its requests. The API handles the decision of where and how to send or retrieve data. It also handles the platform-specific communication - this is the pivot point for the platform agnostic approach. It can decide if it should check Redis (cache) for data being requested, or look in ElasticSearch, request directly from Magento 2 (or whatever your backend platform might be), or any other 3rd party integration you might decide to introduce.

Because it is built in Node, this means you can handle API integrations without exposing keys and such to the client side. It also lets the frontend not worry about system logic, and focus on being a great frontend.

Note - The VSF team is working on a new Storefront API which is being built in a more modular and agnostic way. I believe their intention is for it to be able to be used with any stack, not tied to VSF on the front. I haven't used it yet as it's still not production-ready last time I checked, but I'm excited to try it out.

Vue Storefront

Finally, the part everyone sees - the blazing fast Vue frontend!

Vue Storefront uses Vuex under the hood for state management, and has separated the stores in a modular fashion - similar to Magento's modular approach of extensions in v2. It also has example modules for a great starting point in building your own modules. You can easily include/exclude any modules you wish, because not all shops are alike.

For example, I recently built our own Newsletter module and excluded the built-in Newsletter module. This was because we had so many differences in how we wanted to handle it that it just made more sense than trying to extend the core module to work for us.

The framework is extensible as well, and getting better every day. In addition to standard Vue features like subscribe and subscribeAction, VSF has introduced hooks in key places throughout the core. You can fairly painlessly subscribe to a particular hook to either trigger a reaction to a specific event, or in some cases mutate the data being used after the hook. Bus Events are also used throughout core as another way to easily hook into events to trigger your own behavior at key points.

There is a basic theme which comes with Vue Storefront, though in recent versions they have been pushing to use Capybara as a starting point, or reference point, for your theme building. Of course this is up to you, but it's nice to have a reference when building a theme in a framework like this.

Note - If you look at Vue Storefront, you will see v1 and V2. At the time of building our shop VSF 2 was not ready for Magento. It is a new build of Vue Storefront, but they are focusing on other back-end integrations as the v1 has a solid integration with M2. Just something worth noting. VSF 2 is built on Nuxt, which is exciting as well!

Final words

If you made it this far, thank you for sticking with me! Just a few closing thoughts.

Looking at the architecture, it does seem quite complex compared to a standard Magento setup, but in the end it is totally worth it. Plus, with the separation of technologies, you can separate responsibilities more easily, and it becomes less overwhelming.

One thing that I really enjoy about this setup is that everything is Open Source. Magento has always been open source, and has a massive community. Vue Storefront is open source, along with all of its tools. Their community is rapidly growing, and very active. During our project I was able to contribute to various VSF projects multiple times, as well as participate in community conversations on their Slack/Discord. I truly enjoy working in technologies with this sort of environment, plus it's a nice feeling to know you contributed to a core piece of technology you use day-to-day.

Questions/Comments?

There is so much I didn't get to talk about in this already too long post. If there is something you would like to hear more about, leave a comment and let me know! If it's something I can disclose I'd be happy to write another post about more specific pieces.

Let me know what technology you used for your eCommerce site, I'd love to see what I'm missing out on!

I built my first SaaS on Next.js

Joel Rainwater — Tue, 17 Aug 2021 18:59:59 +0000

Background

I have been a software engineer in some form or fashion for around 10 years, working in anything from Python, PHP, Swift, C# to vanilla JS, jQuery, Vue, and React. Over the past few years I have been getting to know the modern JS framework better, playing around with the different frameworks. I spend most of my days working in Vue, and I have created some side-projects in React to have a better understanding of them both.

I'm not a fan of these tech wars, and to me these JS frameworks are ultimately the same thing. I have enjoyed working in Vue a bit more, but it's just due to personal preference.

The Idea

A few years ago I had to take a car to the mechanic. After a week of not hearing anything I called them. Apparently they needed to replace the engine (it was a known issue with this make/model). This wait... call... wait... call... cycle happened for weeks until the job was complete. I hated it.

So, I had the idea that it could be useful for service-providers to have an easy-to-use platform to provide these status updates to their customers which could notify the customer via email, sms, or push notifications. It could provide a timeline view of the job with the history of updates, etc... And if possible, would be great to integrate into existing tools as to not create too much additional work on their part. But it could same them from repeated customer calls asking the same question - "What's the status of my ____?"

But I didn't do anything about it. Long story short, it took me around 4 years to finally get around to building the thing.

Enter Status Tracker. At the time of writing this it is still in private Early Access. There is a sign-up form on the landing page for those interested in getting early access.

Why Next.js

As I mentioned in my background, I usually prefer Vue, I just enjoy it more, but I'm open to using other technologies for the right reasons. I was planning to build it in Nuxt.js because I haven't used it much but I've heard great things.

And then Max Stoiber released Bedrock. It really had everything already setup out of the box:

TypeScript
GraphQL
GraphQL Codegen and Nexus meant full-stack typing from DB models to client queries and components.
Passport - User auth already setup and ready to go
Stripe - Basic Stripe integration for subscription plans configured and working.
Things like Prettier and ESLint already configured to lint and auto-fix issues while coding and at pre-commit.
Postmark for transactional emails
A few other things...

Overall, it was exactly what I needed for my first time building a SaaS - a boilerplate with the essentials already working. It was ready for me to start adding my custom features to it as soon as I got it. Not to mention Max created a Discord server for those who have purchased a license of Bedrock so that we can support each other and share our projects.

I pre-ordered it before it was released and got it at a great deal. But even at full price it's more than worth it.

So, this setup was definitely worth the switch from Vue to React. It gave me a chance to learn even more about React as well.

Let's get technical

I'll try not to go too deep into details here, but if you are curious to find out more about anything in particular let me know and I can write up a smaller post about it! I'm also not going to drone on about all of the models and views that I created. I just want to cover some of the more fun, interesting, or difficult things I worked on.

Here's what we'll go over:

Hosting
Frontend component library
Email notifications
SMS notifications
URL Shortener
Scheduled jobs
Customer portal with custom branding

Hosting

I decided to try Vercel for hosting this project. I have used Netlify in the past, but since Vercel was built by the same people who built Next.js, and it was originally created for Next.js, I thought it would be a great fit. It was simple to setup and works pretty well. A few caveats I had to work around with my specific setup, but they typically had documentation around this.

For hosting the database (which is Postgres) I went with supabase. I was already using Prisma for the ORM since it came with Bedrock, so I didn't use the SDJ from Supabase. However, it was simple to setup a new account, grab the connection string, and hook it into my existing code. They have a good free tier for a project like this. And I enjoy their UI when using the web app.

Frontend component library

I decided to go with Material-UI for a number of reasons.
For starters, I'm not very strong in design, so I wanted an opinionated frontend framework that would guide me to better design. Something that didn't require very much customization to make it look decent. I have heard great things about Material-UI, and it works great with Next.js. They also provide some nice demos to help inspire my non-creative brain.

I decided on a basic color palette and created a custom theme using their theme config. After that it was mostly import and use, with a few adjustments for spacing and such. It's not beautiful, but my goal was to make it easy to use and understand. I'll worrying about a makeover later.

Email notifications

For sending transactional emails I stuck with Postmark JS as the boilerplate came with it baked in. I could have switched it out fairly easily, but decided to stick with what was ready for me.

I setup some templates in Postmark using their pre-made templates as a starting point. I could define variables in their template (like a user's name or a company/project name). Then using their SDK it was pretty simple to send emails with the intended template and variables. Here's an abbreviated example.

import { Client } from "postmark";
const client = new Client(API_TOKEN);

client.sendEmailWithTemplate({
  From: FROM_EMAIL,
  To: input.to,
  TemplateAlias: input.template,
  TemplateModel: {
    name: input.name,
    company_name: input.company,
    action_url: input.url,
  },
});

Postmark was pretty easy to setup and use, and their default templates are better than what I would have created. So far I am pretty happy with them.

SMS notifications

Originally I did not plan to have SMS notifications. However, I had some conversations with potential customers, and it was brought to my attention that the intended users might be on their phones in the field. For example, a construction crew on the project site. I decided to go ahead and add this, even though it sort of stretched the MVP concept.

For the frontend component, I decided to use Material-UI Phone Number, which is a fork of react-phone-input-2 made for Material-UI. I didn't want to spend time building my own phone number input, but having the auto-format and country select was a nice feature.

I also decided to use google-libphonenumber on the server-side to handle formatting and validation of the phone input.

To send the SMS notifications I went with Amazon SNS. I was hesitant to do this because every time I have worked with anything AWS related I have wasted hours trying to figure out how to get everything configured correctly. Fortunately SNS wasn't too complicated, and their docs helped me through it. One great benefit is that you get something like 1 million requests free on the AWS Free Tier. This should be plenty to get me started.

Here's a truncated version of how I'm using SNS.

import {
  SNSClient,
  PublishCommand,
  PublishCommandInput,
} from "@aws-sdk/client-sns";
import { PhoneNumberFormat, PhoneNumberUtil } from "google-libphonenumber";

export interface SendSMSInput {
  to: string;
  subject: string;
  text: string;
}

const sns = new SNSClient();

// Create instance of phone util for formatting
const phoneUtil = PhoneNumberUtil.getInstance();

export const sendSMS = async (input: SendSMSInput) => {
  // make sure phone is E164 format
  const phone = phoneUtil.parse(input.to);
  const params: PublishCommandInput = {
    Message: input.text,
    PhoneNumber: phoneUtil.format(phone, PhoneNumberFormat.E164),
    Subject: input.subject,
  };
  try {
    return sns.send(new PublishCommand(params));
  } catch (err) {
    console.error(err, err.stack);
    return null;
  }
};

URL Shortener

Once I setup SMS notifications I realized that I would need a URL shortener. Since I'm using the Magic Link authentication process, the URLs can be quite long. In an SMS, this is terrible to see.

After some research, I decided to give Kutt a try. It's open source and free, and there is a node SDK which can make it easy to use.

It was simple to setup and use. Here's a shortened version of how I use it.

import Kutt from "kutt";

export const getShortUrl = async ({ expiresIn, target }) => {
  const kutt = new Kutt();
  kutt.setTimeout(expiresIn);
  const url = await kutt.submit({ target });
  return url.shortUrl;
};

Schedule jobs

Since I decided to host on Vercel, I don't really have a server to run crons on. The backend is all serverless functions. But, one feature that Status Tracker provides is the ability to set a reminder for yourself. For example, when you create a new job, you want to remind yourself 1 hour after the job is scheduled to update the status.

In order to create these scheduled reminders, I needed to be able to have a cron or some sort of scheduled job. I thought about going with another AWS service for this, but once again I'm always hesitant about this.

Then I found Quirrel. Their whole thing is "Quirrel makes job queues simple as cake." This is what I was looking for.

The docs looked simple and straight forward. The technology is open-source. The pricing plans are good for a small Saas like mine. I decided to go for it.

Basically I created an API endpoint to create a new queued job. This endpoint tells Quirrel when to execute the job, and an API endpoint to call at that time. Then I have another endpoint which receives the call from Quirrel at the scheduled time, and it sends the notifications using the referenced data.

The slogan was pretty spot-on. It was simple to setup, the docs walked me through it, and I got it up and running quickly. So far I have been happy with the service as well.

Customer portal

This was the fun part. I wanted to create a custom sub-domain for each organization who uses Status Tracker. I also wanted to give them the ability to use their own branding instead of ours, similar to how Stripe does with their checkout portal.

When a user creates a new organization, they provide the name, and we auto-generate a subdomain. However they are given the choice to change the subdomain if they don't like what we created.

Once the company is created they can configure their branding if they choose under their company settings.

There were two major things I had to figure out at this point.

How could I auto-create the company's subdomain so that I don't have to manually do this each time?
How could I build the customer portal using a dynamic theme which comes from database values?

Creating the subdomains

I didn't want to deal with setting up (even if automated) Nginx configs and SSL certs every time a new company registered. I decided to try using a wildcard subdomain which points to a general customer portal.

I'm using Vercel to host the app, so I pointed my domain servers to Vercle and configured the DNS to use *.statustracker.app for this secondary app. Vercel took care of the SSL cert.

In the app itself (another Next.js client-only app), I created the same theme.ts file with the standard Status Tracker branding as the default theme. I already had a custom _app.tsx file to handle some other things, so in there I added a custom getInitialProps function.

NOTE - I have discovered since building this that perhaps I should be using getServerSideProps instead. I will be testing this change soon.

In this function I call the API to retrieve the company using the slug from the subdomain. If none is found I redirect to the main Status Tracker site. If it does find a company, it returns the theme settings to the component.

Custom branding

In the component where I create the theme provider, I check for any custom theme settings provided by the app props before creating the theme provider, using the default theme as a fallback.

Here is a sample of the difference in branding on the login page.

That's a wrap

That is everything interesting I could think to write about my experience building the app. I plan to write more about the project as it progresses. You can follow me on dev.to, or follow along the milestones of Status Tracker on the Indie Hackers product page.

If you have any questions, or want to know more about something in particular leave a comment and let me know!

Headless Magento - Using Frontend URLs in Emails

Joel Rainwater — Fri, 26 Mar 2021 15:56:53 +0000

Original article: https://blog.rainwater.io/2021/03/26/headless-magento-using-frontend-urls-in-emails

Quick Overview

Magento sends a lot of emails, and most of these emails have pertinent information like the list of products purchased or being shipped, order details, etc... Usually these emails provide a number of links to Magento so that the customer can view their account, order, a product, and so on.

But what can we do if we are using Magento as headless? It will send the customer the Magento URL instead of our frontend URL.

This is the solution I came up with. It might not be the best, but it's working for us.

If you would like to see the final code, I created a sample module to go with this article.

Create a new module

Following Magento's modular approach, let's create a new module to contain this functionality. Throughout this article I'll be using Rain2o_Frontend as the module name in the examples. Remember to replace these with your own module name when following along.

I won't cover how to create a module, this is covered in great detail by many articles as well as the Magento documentation.

Add some configurations

This step might not be necessary for your setup, but I like to keep environment details, like a URL for example, flexible instead of coded so it can be changed per environment easily. To do this, I added a new field in the Stores Configuration section to manage the Frontend URL.

Creating the new field

Create a new file if you haven't already at app/code/Rain2o/Frontend/etc/adminhtml/system.xml.

I decided to add a new group entirely for the Frontend URL field. This is because our setup actually contains multiple fields in this group, but that's just a unique need for our project. Having this separate group allows us to have a separate section that's easy to find and ready to grow as additional requirements are introduced.

This is what I have in system.xml:

<!-- app/code/Rain2o/Frontend/etc/adminhtml/system.xml -->
<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Config:etc/system_file.xs">
    <system>
        <section id="web">
            <group id="frontend" translate="label comment" type="text" sortOrder="25" showInDefault="1" showInWebsite="1" showInStore="1">
                <label>Frontend URLs</label>
                <field id="base_url" translate="label comment" type="text" sortOrder="10" showInDefault="1" showInWebsite="1" showInStore="1">
                    <label>Frontend Base URL</label>
                    <comment><![CDATA[Specify full URL for frontend.]]></comment>
                </field>
            </group>
        </section>
    </system>
</config>

This is fairly straight-forward if you're familiar with Magento's system.xml file, but I'll break it down a little.

We are adding one new field called base_url inside a new group we created called frontend. This is all inside Magento's existing section web, which can be found in the admin at Stores -> Configuration -> General -> Web.

This field is set to be editable in all scopes - Global, Website, and Store. This is up to you and your needs. Just note that I handle multi-store functionality later, so there is no need to set this per store here. But you can do so if that fits your needs.

Setting default value

Let's set a default value too, just so there's something to start with.

Create the file app/code/Rain2o/Frontend/etc/config.xml. Here I set the production URL as the default. This can be changed in Magento per environment, but this guarantees production will start with the right value.

<!-- app/code/Rain2o/Frontend/etc/config.xml -->
<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Store:etc/config.xsd">
    <default>
        <web>
            <frontend>
                <base_url>https://shop.example.com/</base_url>
            </frontend>
        </web>
    </default>
</config>

Now, install the module if you haven't already:

bin/magento setup:upgrade

Or, if the module is already installed, clean the cache:

bin/magento cache:clean

Once you do that, you should see this in the Web configuration section:

How are URLs created in Emails?

Alright, now that the groundwork is done, let's figure out how to override the URLs generated in emails.

Feel free to skip this part. I prefer to understand what I'm changing and why it is done in a certain way, so I wanted to help provide these details. If you just want to do the work, go to the next step.

After some digging, I discovered Magento's email templates use the model \Magento\Email\Model\Template for building the emails, which extends \Magento\Email\Model\AbstractTemplate.

In AbstractTemplate you will see the function getUrl, which is what is used in the email templates. This uses the private property $urlModel, which is passed to the __construct as a dependency. The model that is used by default is \Magento\Framework\Url.

Digging around in \Magento\Framework\Url, we can see that there are two main functions that could be useful in generating the correct frontend URLs - getRouteUrl and getBaseUrl. Both of these functions are ultimately called from the getUrl function which is initially called in the template. getBaseUrl is where we can use the new field we just created for the base. But our frontend might not follow the same routing structure as Magento, so getRouteUrl is where we can handle those route changes.

But how do we do that without hacking core? Both of those functions are public, so we could use Plugins. But I chose instead to use dependency inject to inject a new URL model for email templates. This avoids having multiple plugins on a model which is probably used a lot throughout Magento, and instead gives us a single Model to handle all frontend URL logic. We can then use this model later as we discover new parts of Magento that might need this functionality.

Overriding email URLs

Let's use Magento's Dependency Inject file to change the model which is passed to the email template for urlModel.

Inject our own URL model

Create the file app/code/Rain2o/Frontend/etc/di.xml. Here we will tell Magento to use our own URL Model in the __construct of \Magento\Email\Model\Template.

<!-- app/code/Rain2o/Frontend/etc/di.xml -->
<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">
    <type name="Magento\Email\Model\Template">
        <arguments>
            <argument name="urlModel" xsi:type="object" shared="false">Rain2o\Frontend\Model\Url</argument>
        </arguments>
    </type>
</config>

We told Magento that the urlModel argument for the class \Magento\Email\Model\Template should use our own model (we haven't created it yet) instead of the default model.

Create our new URL Model

Now let's create the model we just referenced. This is where the good stuff will happen.

Create your model app/code/Rain2o/Frontend/Model/Url.php. If you look again at the Email Template model, you'll see that urlModel is passed as \Magento\Framework\UrlInterface $urlModel. Since we are changing the model for this, we need to be sure our model also implements that interface.

First let's create the class skeleton, then we'll add in the pieces.

NOTE - I am leaving out DocBlocks and comments to keep the sample code slim. Don't forget to document your code thoroughly!

<?php /** app/code/Rain2o/Frontend/Model/Url */
declare(strict_types=1);

namespace Rain2o\Frontend\Model;

use Magento\Framework\UrlInterface;

class Url extends \Magento\Framework\Url implements UrlInterface
{
    // ...
}

As you can see I extended the model we are replacing - Magento\Framework\Url. This will allow us to use existing functionality without rewriting it, and only replace the pieces we need to modify.

Get Frontend URL from config

The first thing we know we're going to need to do is get the value of the new field we added in system.xml. Fortunately, the model we are extending already has a protected function _getConfig to get config values.

At the top of the class, let's add a constant to contain the path to our new field:

const FE_URL_PATH = "web/frontend/base_url";

We also want to make sure that our frontend URL logic is only executed if the current scope is for frontend. So let's go ahead and add a flag to indicate if we're in admin scope or not. We'll use this later.

/**
 * @var bool
 */
private $isAdmin = false;

The base model is rather large, and this next part can be daunting. So let's start from the bottom and work our way up. The first thing we need to modify is the base url. So let's copy the public function getBaseUrl($params = []) {} function to our new model from the original in Magento\Framework\Url. We will add a few pieces into the existing code. Here's the final version of the function, we'll break it down next.

public function getBaseUrl($params = [])
{
    /**
     *  Original Scope
     */
    $this->origScope = $this->_getScope();

    if (isset($params['_scope'])) {
        $this->setScope($params['_scope']);
    }

    // CUSTOM CODE
    // we only want to override if we're in frontend
    if ($this->_getScope()->getCode() === 'admin') {
        $this->isAdmin = true;
        return parent::getBaseUrl($params);
    } else {
        $this->isAdmin = false;
    }
    // END CUSTOM CODE

    if (isset($params['_type'])) {
        $this->getRouteParamsResolver()->setType($params['_type']);
    }

    if (isset($params['_secure'])) {
        $this->getRouteParamsResolver()->setSecure($params['_secure']);
    }

    /**
     * Add availability support urls without scope code
     */
    if ($this->_getType() == UrlInterface::URL_TYPE_LINK
        && $this->_getRequest()->isDirectAccessFrontendName(
            $this->_getRouteFrontName()
        )
    ) {
        $this->getRouteParamsResolver()->setType(UrlInterface::URL_TYPE_DIRECT_LINK);
    }

    // CUSTOM CODE
    // remove slash so we can add one and know it's only one
    $result = rtrim($this->_getConfig(self::FE_URL_PATH), "/") . "/";
    // add store code
    $result .= $this->_getScope()->getCode() . "/";
    // END CUSTOM CODE

    // setting back the original scope
    $this->setScope($this->origScope);
    $this->getRouteParamsResolver()->setType(self::DEFAULT_URL_TYPE);

    return $result;
}

I surrounded any additions or changes in comments to make it easier to see what we modified.

The first thing we did was check the current scope. If it's admin we set our $this->isAdmin flag to true (we will check this in other functions later), and then return the execution of the parent function. This way we don't modify the behavior for admin URLs, and we stop any further execution of our custom logic.

The second change was how we create $result. Instead of using Magento's built in function (previously it was $this->_getScope()->getBaseUrl(...), we want to use our new value.

So we modified it to be

$result = rtrim($this->_getConfig(self::FE_URL_PATH), "/") . "/";

The rtrim is just an extra precaution to ensure there is always one, and only one slash at the end. Since this is a field in Magento configuration, we can't always control that, so we force it this way.

The next line we add the store code to the URL. Of course this is optional according to your setup. We actually use locales in our frontend URLs, so I have additional logic to convert the store code to the appropriate local, but that's not necessary for this article.

$result .= $this->_getScope()->getCode() . "/";

You can modify this to fit your store's needs.

And that's it for that function. We now should be retrieving the frontend base URL with store code.

Handling routes

The other function I mentioned earlier is getRouteUrl. This is where we need to handle our route patterns for the frontend. The parent model we are extending uses Magento code for generating routes which we want to bypass. The actual logic for that is in a couple of protected functions we'll look at next. The code for this function is pretty slim.

public function getRouteUrl($routePath = null, $routeParams = null)
{
    // get our new base URL for frontend
    $base = $this->getBaseUrl($routeParams);

    // use parent if we're in admin scope
    if ($this->isAdmin) {
        return parent::getRouteUrl($routePath, $routeParams);
    }

    // route mapping happens here
    $this->_setRoutePath($routePath);

    // use our base url and the mapped route path
    $frontUrl = $base . $this->_getRoutePath($routeParams);

    return $frontUrl;
}

First we get the new base url we just created. Next we check if we're in admin scope, and if so then just execute the parent function again. Otherwise we call $this->_setRoutePath(), which is where the actual mapping of routes happens.

And finally we combine all of the above work to create our full frontend URL with route.

Mapping the routes

Now we need to handle the mapping of routes. First we'll create our own _setRoutePath function to handle this. If you look at the parent class, this function uses a lot of Magento code like $this->_getRequest()->getControllerName(); and similar. We don't want any of this for our frontend. This function actually gets a bit smaller, depending on your mapping needs.

For our setup, we actually have pretty straightforward routes, so we don't have any mapping logic. Instead we just use the route path as-is, because that matches our frontend routes.

protected function _setRoutePath($data)
{
    // kept from original
    if ($this->_getData('route_path') == $data) {
        return $this;
    }

    $this->unsetData('route_path');
    $routePieces = explode('/', $data);

    // additional logic here if needed to map route path to frontend routes
    $pieces = $this->yourFunctionForMappingRoutes($routePieces);

    $this->setData('route_path', implode("/", $pieces));
    return $this;
}

Most of the code we have is kept from the original function, but we removed a lot of unused code. I placed a comment where you could implement custom logic for mapping routes according to your needs. This will be different for everyone.

We set the data after handling the mapping, and we're done.

Getting the mapped routes

We also need to remove some logic from the _getRoutePath function, because it uses some additional Magento logic for rewrites that we don't need.

protected function _getRoutePath($routeParams = [])
{
    // use parent function if we're in admin scope
    if ($this->isAdmin) {
        return parent::_getRoutePath($routeParams);
    }
    return $this->_getData('route_path');
}

We first check if we're in admin, and if so execute the parent function again. After that we only return the previously set route_path data.

And that does it. Now if you clean the cache - bin/magento cache:clean, you should be able to test your emails and find the new frontend URLs.

Final Look

Here is the final version of our URL model

<?php
declare(strict_types=1);
namespace Rain2o\Frontend\Model;

use Magento\Framework\UrlInterface;

class Url extends \Magento\Framework\Url implements UrlInterface
{
    const FE_URL_PATH = "web/frontend/base_url";

    /**
     * @var bool
     */
    private $isAdmin = false;

    public function getBaseUrl($params = [])
    {
        /**
         *  Original Scope
         */
        $this->origScope = $this->_getScope();

        if (isset($params['_scope'])) {
            $this->setScope($params['_scope']);
        }

        // CUSTOM CODE
        // we only want to override if we're in frontend
        if ($this->_getScope()->getCode() === 'admin') {
            $this->isAdmin = true;
            return parent::getBaseUrl($params);
        } else {
            $this->isAdmin = false;
        }
        // END CUSTOM CODE

        if (isset($params['_type'])) {
            $this->getRouteParamsResolver()->setType($params['_type']);
        }

        if (isset($params['_secure'])) {
            $this->getRouteParamsResolver()->setSecure($params['_secure']);
        }

        /**
         * Add availability support urls without scope code
         */
        if ($this->_getType() == UrlInterface::URL_TYPE_LINK
            && $this->_getRequest()->isDirectAccessFrontendName(
                $this->_getRouteFrontName()
            )
        ) {
            $this->getRouteParamsResolver()->setType(UrlInterface::URL_TYPE_DIRECT_LINK);
        }

        // CUSTOM CODE
        // remove slash so we can add one and know it's only one
        $result = rtrim($this->_getConfig(self::FE_URL_PATH), "/") . "/";
        // add store code
        $result .= $this->_getScope()->getCode() . "/";
        // END CUSTOM CODE

        // setting back the original scope
        $this->setScope($this->origScope);
        $this->getRouteParamsResolver()->setType(self::DEFAULT_URL_TYPE);

        return $result;
    }

    public function getRouteUrl($routePath = null, $routeParams = null)
    {
        // get our new base URL for frontend
        $base = $this->getBaseUrl($routeParams);

        // use parent if we're in admin scope
        if ($this->isAdmin) {
            return parent::getRouteUrl($routePath, $routeParams);
        }

        // route mapping happens here
        $this->_setRoutePath($routePath);

        // use our base url and the mapped route path
        $frontUrl = $base . $this->_getRoutePath($routeParams);

        return $frontUrl;
    }

    protected function _setRoutePath($data)
    {
        // kept from original
        if ($this->_getData('route_path') == $data) {
            return $this;
        }

        $this->unsetData('route_path');
        $routePieces = explode('/', $data);

        // additional logic here if needed to map route path to frontend routes
        $pieces = $this->yourFunctionForMappingRoutes($routePieces);

        $this->setData('route_path', implode("/", $pieces));
        return $this;
    }

    protected function _getRoutePath($routeParams = [])
    {
        // use parent function if we're in admin scope
        if ($this->isAdmin) {
            return parent::_getRoutePath($routeParams);
        }
        return $this->_getData('route_path');
    }
}

Closing remarks

There will be plenty of edge-cases and unique needs in something like this, so your implementation will probably vary and grow over time. This is a simplified version of what we have implemented, as some of our needs were unique and not valuable to this tutorial.

I am hoping one day Magento implements a built-in solution for these types of issues, especially with the PWA Studio being a thing now. Until then, we will continue to help each other find our own solutions.

Do you have a better solution? Did this work for you? Let me know, I'd love to check out better solutions if possible!

Using field dependency in Magento 2

Joel Rainwater — Wed, 16 Dec 2020 22:37:57 +0000

Skip the details, show me the code

Quick Summary

One of the most common questions I see and have asked myself for Magento 2 is how to create fields that are dynamically visible, dependent on the value of another field. This article will walk through how to do this using the tools already provided by Magento.

I have seen a lot of solutions out there, most of which involve building this feature yourself with some custom Javascript, which is just fine however I prefer to use the tools already provided by the system when available. This article is an extension of my answer on the Magento Stack Exchange here -

Dec 31 '18

This is an old question with multiple answers that work, however I have discovered a solution using what Magento provides (as of 2.1.0) without the need for extending components. As multiple questions have been marked as duplicate and directed here I thought it would be beneficial to provide some information…

Open Full Answer

Behind the Curtain

The steps in this article walk through how to implement this functionality. But to give you a high-level view at what functionality we will be taking advantage of, and where you can find it used in the wild (i.e. core Magento), here's some quick info.
All form element ui components that extend Magento_Ui/js/form/element/abstract.js have a switcherConfig setting available for purposes such as hiding/showing elements as well as other actions. The switcher component can be found at Magento_Ui/js/form/switcher for the curious. You can find examples of it being used in sales_rule_form.xml and catalog_rule_form.xml. Of course if you are using your own custom component already you can still use this as long as your component eventually extends abstract.

Requirements

This article was written using Magento 2.3, however this feature has been available as of Magento 2.1.0.
This article assumes you have a custom module you are implementing this functionality into. If you need help building a module, check out the Magento dev docs.

Set the Stage

To make things easier, let's define some requirements for a feature we're going to build. I am going to use an example of something I built recently so that I can give real examples.

Let's say you have created a new entity in Magento called a Shipping Carrier, and you have created a view in admin to edit these Shipping Carriers. To use the feature we are discussing in this article, you should be using Magento's UI Components. More on that later.

While editing a Shipping Carrier, we want the ability to enable Tracking for some carriers, and if Tracking is enabled we want to provide a Tracking URL. We will create two fields for this:

Tracking Enabled (tracking_enabled)
Tracking URL (tracking_url)

To make things cleaner for the content editors, we will hide the Tracking URL field unless Tracking Enabled is set to Enabled (yes this is redundant, but naming is the hardest part of being a developer, right?). Below is a screen recording of the end result we will be trying to accomplish.

For the purposes of this article, I will skip the creation of a module and the creation of the Shipping Carrier controller and UI Component form, as this is focused on toggling visibility of fields in a UI Component form. You can find a number of articles showing how to create UI Component forms in Magento 2.

What to do

Finally, let's get started on the code. Once you have created your module and the appropriate controller and layout, you should have a file in your module like {Namespace}/{ModuleName}/view/adminhtml/ui_component/shipping_carrier_form.xml. This file will change depending on what type of entity you are working on, and the name of the UI Component form you created. For the Product Edit form for example, it would be product_form.xml.

First, let's add our two new fields to the shipping_carrier_form UI Component form. The relevant part of the file will look something like this.



<?xml version="1.0" encoding="UTF-8"?>
<form xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Ui:etc/ui_configuration.xsd">
  ...
  <fieldset name="carrier_information" sortOrder="10">
    ...
    <field name="tracking_enabled" formElement="select">
      <argument name="data" xsi:type="array">
        ...
      </argument>
      <settings>
        <validation>
          <rule name="required-entry" xsi:type="boolean">true</rule>
        </validation>
        <dataType>number</dataType>
        <label translate="true">Tracking Enabled</label>
        <scopeLabel>[WEBSITE]</scopeLabel>
        <visible>true</visible>
        <dataScope>tracking_enabled</dataScope>
      </settings>
      <formElements>
        <select>
          <settings>
            <options>
              <option name="0" xsi:type="array">
                <item name="value" xsi:type="number">1</item>
                <item name="label" xsi:type="string" translate="true">Enabled</item>
              </option>
              <option name="1" xsi:type="array">
                <item name="value" xsi:type="number">0</item>
                <item name="label" xsi:type="string" translate="true">Disabled</item>
              </option>
            </options>
          </settings>
        </select>
      </formElements>
    </field>
    <field name="tracking_url" formElement="input">
      <argument name="data" xsi:type="array">
        ...
      </argument>
      <settings>
        <validation>
          <rule name="required-entry" xsi:type="boolean">true</rule>
        </validation>
        <dataType>text</dataType>
        <label translate="true">Tracking URL</label>
        <scopeLabel>[WEBSITE]</scopeLabel>
        <visible>true</visible>
        <dataScope>tracking_url</dataScope>
      </settings>
    </field>
  </fieldset>
</form>

So now we have the two fields always visible and always required for Shipping Carriers. To see the changes you may need to clear cache if you have it enabled.

Now, let's get to the problem at hand. We want to hide the Tracking URL field unless Tracking is Enabled. At this point, we need to add a bit of XML into the controller field. By controller field, I mean the field that controls the visibility of the other field(s). In our case, this will be the field tracking_enabled. We need to add <switcherConfig> inside the <settings> node of this field. It should look something like this.



<switcherConfig>
  <rules>
    <rule name="0">
      <value>0</value>
      <actions>
        <action name="0">
          <target>shipping_carrier_form.shipping_carrier_form.carrier_information.tracking_url</target>
          <callback>hide</callback>
        </action>
      </actions>
    </rule>
    <rule name="1">
      <value>1</value>
      <actions>
        <action name="0">
          <target>shipping_carrier_form.shipping_carrier_form.carrier_information.tracking_url</target>
          <callback>show</callback>
        </action>
      </actions>
    </rule>
  </rules>
  <enabled>true</enabled>
</switcherConfig>

Now the Tracking URL field will be hidden unless the Tracking Enabled field is set to Enabled. It will also only be required if it is visible. But let's break down what we just added so we can understand what it does.

The <switcherConfig> component contains an array of rules which is what we're building out here. Each <rule> has a name which is a number in this example. This name is the array index for this item. As these are arrays, they should start with 0, not strings or 1.

Inside each <rule> we pass two arguments.

<value> - This is the value of tracking_enabled which should trigger the actions defined below.
<actions> - Here we have another array. These are the actions to be triggered when this rule's conditions are met. Again, each action's name is just the array index of that item.

Now each <action> has two arguments as well (with an optional 3rd).

<target> - This is the element you wish to manipulate under this action. If you aren't familiar with how ui_component element names are composed in Magento you can check out Alan Storm's article. It's basically something like {component_name}.{component_name}.{fieldset_name}.{field_name} in this example.
<callback> - Here is the action to be taken on the above mentioned target. This callback should be a JavaScript function that is available on the element targeted. Our example uses hide and show. This is where you can start to expand on the functionality available. The catalog_rule_form.xml example I mentioned earlier uses setValidation if you wish to see a different example.
You can also add <params> to any <action> that calls for them. You can see this in the catalog_rule_form.xml example as well.

Finally the last item inside <switcherConfig> is <enabled>true</enabled>. This should be pretty straight forward, it's a Boolean to enable/disable the switcher functionality we just implemented.

And we're done! The final XML for our new fields should look like this.



<field name="tracking_enabled" formElement="select">
  <argument name="data" xsi:type="array">
    ...
  </argument>
  <settings>
    <validation>
      <rule name="required-entry" xsi:type="boolean">true</rule>
    </validation>
    <dataType>number</dataType>
    <label translate="true">Tracking Enabled</label>
    <scopeLabel>[WEBSITE]</scopeLabel>
    <visible>true</visible>
    <dataScope>tracking_enabled</dataScope>
    <switcherConfig>
      <rules>
        <rule name="0">
          <value>0</value>
          <actions>
            <action name="0">
              <target>shipping_carrier_form.shipping_carrier_form.carrier_information.tracking_url</target>
              <callback>hide</callback>
            </action>
          </actions>
        </rule>
        <rule name="1">
          <value>1</value>
          <actions>
            <action name="0">
              <target>shipping_carrier_form.shipping_carrier_form.carrier_information.tracking_url</target>
              <callback>show</callback>
            </action>
          </actions>
        </rule>
      </rules>
      <enabled>true</enabled>
    </switcherConfig>
  </settings>
  <formElements>
    <select>
      <settings>
        <options>
          <option name="0" xsi:type="array">
            <item name="value" xsi:type="number">1</item>
            <item name="label" xsi:type="string" translate="true">Enabled</item>
          </option>
          <option name="1" xsi:type="array">
            <item name="value" xsi:type="number">0</item>
            <item name="label" xsi:type="string" translate="true">Disabled</item>
          </option>
        </options>
      </settings>
    </select>
  </formElements>
</field>
<field name="tracking_url" formElement="input">
  <argument name="data" xsi:type="array">
    ...
  </argument>
  <settings>
    <validation>
      <rule name="required-entry" xsi:type="boolean">true</rule>
    </validation>
    <dataType>text</dataType>
    <label translate="true">Tracking URL</label>
    <scopeLabel>[WEBSITE]</scopeLabel>
    <visible>true</visible>
    <dataScope>tracking_url</dataScope>
  </settings>
</field>

Good luck with your dynamic fields! Feel free to post comments if this article helped you build something, or if you have any questions or other feedback.