DEV Community: Stephen Whitmore

Automatically send emails using Google SMTP with 3 easy steps

Stephen Whitmore — Tue, 10 Jan 2023 00:10:16 +0000

If you need to automate tasks then you'll likely find this post useful. I like to be notified if an automated script fails or succeeds, depending on the situation.

You can get your scripts to email you using Google's SMTP server:

1. Set up a Gmail Password

Assuming you have a Google account and are signed in, visit https://myaccount.google.com/apppasswords.

Select "Other" from the Select app drop down:

Give the app password a name. It can be whatever. Click "Generate" and you'll see something like this:

Save this somewhere else it shall be lost to the void.

When you click done your new app password will show up for you:

2. Install mutt

If you're on Linux your distro will likely have the mutt package available in its repositories:

Fedora/RHEL/CentOS

sudo dnf install mutt

or

sudo yum install mutt

Ubuntu/Debian

sudo apt install mutt

Arch/Manjaro

sudo pacman -S mutt

Bonus: mutt is also available on MacOS via Homebrew:

brew install mutt

3. Configure mutt

Create a .muttrc file in your home directory.

vi ~/.muttrc

Fill it out with the configs, pasting in your app password from step 1 for the smtp_pass value:

set from = "<gmail-id>@gmail.com"
set realname = "<Your Name>"
set smtp_url = "smtp://<gmail-id>@smtp.gmail.com:587/"
set smtp_pass = "<smtp password generated in the google link above>"

In our case "smtp password generated in the google link above" is vaykiyyakisiqmez.

Now test it out -

echo "This is an email body." | mutt -s "This is an email subject" recipient@example.com

Tada! 🎉

You are going to fail

Stephen Whitmore — Thu, 05 Jan 2023 18:03:35 +0000

I pride myself on the fact that I have never had to ask for help. I have never felt overwhelmed or out of my depth. I've never made egregious errors that forced me to scramble for a quick solution. I've never faced a challenge so daunting that I began to question all of my life choices.

Do I have your attention? Your ire, perhaps? Good. Because everything I just said above is a complete lie and I have absolutely done all of those things on more than one occasion.

Writing code is hard. Writing good code is really hard. This is why so many of us experience burnout and imposter syndrome. We are the mental equivalent of professional athletes. We're competitive, always training, and always need to be at the top of our game.

That kind of pressure lives in the back of our minds. We may take a look around and see just how much we don't know and feel inferior. After working in this field for 10 years I'm here to share a little secret:

Senior developers are just junior developers who have had more time to make more mistakes.

That's right. We're not smarter than you. We haven't tapped some mysterious force of knowledge or wisdom. We've just faceplanted so many times that we've finally learned a few lessons.

I still struggle with burnout and imposter syndrome. Only now, after having overcome so many hurdles, there's a small part of me that knows that I'll probably be fine and will figure things out.

Persistence is the #1 ingredient to being a successful software developer.

So fail my friends. Fail with enthusiasm. Because failure leads to learning and learning leads to growth.

Angular Unit Tests: Common Pain Points

Stephen Whitmore — Mon, 21 Nov 2022 20:59:26 +0000

One of the biggest struggles I see when people are first learning Angular is dealing with unit tests. They can be painful when you're new to the framework or are used to dealing with backend code.

The biggest pain points I think people run into are:

The setup
The scope
Testing Observables
Dealing with lifecycle hooks

I wanted to post a quick blurb that may come in handy for those who are struggling today. Hopefully after reading this you'll feel a bit more comfortable when facing Angular unit tests in the future.

The Setup

Keep it simple! This tends to be the first place people get tangled up. Only set up what you absolutely need.

Golden rules to follow for setting up your tests:

Keep it simple.
Don't import modules unless absolutely necessary (e.g. ReactiveFormsModule if you have form elements in the component or RouterModule if you have routerLinks).
Never use the NO_ERRORS_SCHEMA.
Never provide real services when testing components, even if they don't make http calls.

I can't overemphasize the first rule. Tests, and their setup, should be simple. Regardless of how complicated an application or its components may be.

Let's say we have a component that looks something like this:

export class CustomerSummaryComponent implements OnInit, OnDestroy {
  updateListenerSub = new Subscription();
  customerData$: Observable<CustomerDataModel> | undefined;

  constructor(
    private activatedRoute: ActivatedRoute,
    private customerDataService: CustomerDataService,
    private mmmToastService: MmmToastService,
  ) {}

  ngOnInit(): void {
    this.getCustomerData();
    this.listenForUpdates();
  }

  getCustomerData() {
    const customerNumber = this.activatedRoute.snapshot.params['customerNumber'];
    const customerLastName = this.activatedRoute.snapshot.params['lastName'];

    this.customerData$ = this.customerDataService.getCustomerData(customerNumber, customerLastName);
  }

  listenForUpdates() {
    this.updateListenerSub = this.customerDataService.customerUpdated$
      .subscribe({
        next: (response: CustomerUpdateModel) => this.showToastMessage(response),
        error: (error: any) => this.showToastMessage(error),
      });
  }

  showToastMessage(response: CustomerUpdateModel) {
    const type = response.status === 200 ? 'success' : 'error';

    this.mmmToastService.addToast({ type, message: response.message });
  }

  ngOnDestroy(): void {
    this.updateListenerSub.unsubscribe();
  }
}

There are a few things going on here. We have a couple services, we're dealing with the ActivatedRoute, and we have a couple lifecycle hooks.

Here's what the setup should look like for our tests:

describe('CustomerSummaryComponent', () => {
  let component: CustomerSummaryComponent;
  let fixture: ComponentFixture<CustomerSummaryComponent>;

  beforeEach(() => {
    TestBed.configureTestingModule({
      declarations: [ CustomerSummaryComponent ],
      providers: [
        { provide: ActivatedRoute, useValue: activatedRouteStub },
        { provide: CustomerDataService, useValue: customerDataServiceStub },
        { provide: MmmToastServiceStub, useValue: mmmToastServiceStub },
      ],
    });

    fixture = TestBed.createComponent(CustomerSummaryComponent);
    component = fixture.componentInstance;
  });

That's it. We have stubs for our services and we're loading up our component into the test harness. We don't need to care about anything else at this point.

You should be mindful of importing modules because doing so can put way more into your test harness than what's needed and can ultimately lead to unintended side-effects.

The NO_ERRORS_SCHEMA is a big blanket that'll mask real errors in your application code. You can read more about what it does here, but I'd recommend just staying away from it altogether.

Services generally either have http calls or business logic in them. Your unit tests for this component shouldn't know or care about any of that. Which leads me to my next point...

The Scope

Keep the scope of your tests as narrow as possible. The more narrow your test focus is, the bigger the return you'll get. They'll also be easier to write and manage.

Let's take another look at the getCustomerData() method from our component above.

getCustomerData() {
    const customerNumber = this.activatedRoute.snapshot.params['customerNumber'];
    const customerLastName = this.activatedRoute.snapshot.params['lastName'];

    this.customerData$ = this.customerDataService.getCustomerData(customerNumber, customerLastName);
}

In this method we're grabbing some data from the ActivatedRoute, passing it to our service, and storing the result in an Observable.

Before we go any further let me outline some things that we're NOT trying to test:

How ActivatedRoute behaves
What happens in customerDataService.getCustomerData()

We only care that we're making a call to our service, what we're passing to it, and what we do in response to that call.

That's why we use stubs. Our stubs will just give us what we want so we can focus on what we do care about.

Here's a good set of tests for our getCustomersData() method:

beforeEach(() => {
    // ...
    activatedRouteStub.testParams = { customerNumber: '1234', customerLastName: 'Smith' };
});

describe('getCustomerData()', () => {
    it('should call "customerDataService.getCustomerData()" with the route params', () => {
        const spy = spyOn(customerDataServiceStub, 'getCustomerData');

        component.getCustomerData();

        expect(spy).toHaveBeenCalledOnceWith('1234', 'Smith');
    });

    it('should put the returned value in an observable', () => {
      spyOn(customerDataServiceStub, 'getCustomerData').and.returnValue(of());
      component.getCustomerData();

      expect(component.customerData$).toBeTruthy();
    });
});

Each test has a narrow focus and is following that AAA structure (Assemble, Act, Assert). Our activatedRouteStub and customerDataServiceStub are just bouncing back what we need to make our assertions. They would look something like this:

export class ActivatedRouteStub {
    private subject = new BehaviorSubject(this.testParams);
    private _testParams: any;

    get testParams() {
        return this._testParams;
    }

    set testParams(queryParams: any) {
        this._testParams = queryParams;
        this.subject.next(queryParams);
    }

    get snapshot() {
        return {
          queryParams: this.testParams,
          params: this.testParams,
        };
      }    
}

export class CustomerDataServiceStub {
    getCustomerData(customerNumber: string, customerLastName: string): any {}
}

Put the bare minimum in your stubs. They should be "stupid"!

Testing Observables

This is a big pain point. When we're dealing in async space we risk subjecting ourselves to test bleedover and unintended side-effects. That's why it's important to wrap our tests in fakeAsync and to always flush when we're done 😁.

Let's take a look at a couple scenarios where we're forced to deal with an Observable:

With that first method getCustomerData() we originally just asserted that our customerData$ property wasn't falsy. That's fine, but it would be better if we could crack open that Observable and make sure what we expect is inside:

const mockCustomer = {
    firstName: 'John',
    lastName: 'Doe',
    customerNumber: '12345',
    memberSince: new Date('11/11/2011'),
    email: 'johndoe@email.com',
    phone: '555-777-9999',
};

describe('getCustomerData()', () => {
    //...

    it('should put the returned value in an observable', fakeAsync(() => {
      spyOn(customerDataServiceStub, 'getCustomerData').and.returnValue(of(mockCustomer));

      component.getCustomerData();

      component.customerData$
        .subscribe({
          next: (response: CustomerDataModel) => {
            expect(response).toEqual(mockCustomer)
          }
        });

      flush();
    }));
});

By wrapping our test in fakeAsync we're able to test asynchronous code in a synchronous way. There are plenty of articles out there describing how this works in more detail and I encourage you to read up on it. In the meantime, just think of it as a nice tool to keep headaches in our tests to a minimum.

Calling flush() either at the end of each test wrapped in fakeAsync or in a afterEach() method will ensure that anything going on in async space is wrapped up. This will help prevent test bleedover.

Our listenForUpdates() is another good scenario for testing in async space.

listenForUpdates() {
    this.updateListenerSub = this.customerDataService.customerUpdated$
        .subscribe({
            next: (response: CustomerUpdateModel) => this.showToastMessage(response),
            error: (error: any) => this.showToastMessage(error),
        });
}

We can maintain that AAA structure if customerUpdated$ is a BehaviorSubject.

  describe('listenForUpdates()', () => {
    it('should call "showToastMessage()" with response', fakeAsync(() => {
      const spy = spyOn(component, 'showToastMessage');
      customerDataServiceStub.update(); // trigger ".next()" on the observable to make it emit

      component.listenForUpdates();

      expect(spy).toHaveBeenCalledTimes(1);
    }));
  });

customer-data-service.stub.ts

export class CustomerDataServiceStub {
    customerUpdated$ = new BehaviorSubject({message: 'Yay!', status: 200});

    getCustomerData(customerNumber: string, customerLastName: string): any {}

    update() {
        this.customerUpdated$.next({message: 'updated', status: 200});
    }
}

This is because BehaviorSubjects immediately emit values when they're subscribed to. If customerUpdated$ was a regular Subject we'd need to break that AAA structure a little bit:

  describe('listenForUpdates()', () => {
    it('should call "showToastMessage()" with response', fakeAsync(() => {
      const spy = spyOn(component, 'showToastMessage');
      customerDataServiceStub.update();

      customerDataServiceStub.customerUpdated$
        .subscribe({
          next: () => expect(spy).toHaveBeenCalledTimes(1)
        });

      component.listenForUpdates();
    }));
  });

The sooner you can get comfortable with Observables, the better. They can feel daunting at first but once you get used to them they really are magical. Some good points to focus on would be:

Learning the differences between the more widely used Subject types (Subject, BehaviorSubject, ReplaySubject)
Learning the most commonly used operators (map, mergeMap/switchMap, combineLatest, takeUntil, to name a few)

Dealing with lifecycle hooks

In short, don't test these. We want to test our code - not the framework we're using.

Let's change our CustomerSummary component a bit so that it's recieving data from a parent instead of fetching said data. We'll have it capture
the customer's first name into a class property as well:

export class CustomerSummaryComponent implements OnInit, OnDestroy {
  updateListenerSub = new Subscription();
  @Input() customerData: CustomerDataModel;
  firstName: string;

  constructor(
    private activatedRoute: ActivatedRoute,
    private customerDataService: CustomerDataService,
    private mmmToastService: MmmToastService,
  ) {}

  ngOnChanges(changes: SimpleChanges): void {
    const customerChange = changes['customerData'];

    if (customerChange && customerChange.currentValue) {
        this.firstName = customerChange.currentValue.firstName;
    }
  }

  //...
}

I see a lot of tests like below:

describe('ngOnChanges()', () => {
    it('should capture the first name of the customer', () => {
        const changes = { customerData: new SimpleChange(null, mockCustomer, true) };

        component.ngOnChanges(changes);

        expect(component.firstName).toBe('John');
    });
});

You're not really getting any real value out of a test like this. If there's logic in the lifecycle hook you should break the logic out into their own methods. It'll make the application code easier to test, manage, and read!

ngOnChanges(changes: SimpleChanges): void {
    const customerChange = changes['customerData'];

    if (customerChange && customerChange.currentValue) {
        const currentCustomer = customerChange.currentValue;
        this.firstName = currentCustomer.firstName;

        this.updateListenerSub = this.customerDataService.customerUpdated$
            .subscribe({
                next: (response: CustomerUpdateModel) => this.showToastMessage(response),
                error: (error: any) => this.showToastMessage(error),
            });
    }
  }

becomes

ngOnChanges(changes: SimpleChanges): void {
    const customerChange = changes['customerData'];

    if (customerChange && customerChange.currentValue) {
        this.captureFirstName(customerChange.currentValue);
        this.listenForupdates();
    }
}

captureFirstName(currentCustomer) {
    this.firstName = currentCustomer.firstName;
}

listenForUpdates() {
    this.updateListenerSub = this.customerDataService.customerUpdated$
        .subscribe({
            next: (response: CustomerUpdateModel) => this.showToastMessage(response),
            error: (error: any) => this.showToastMessage(error),
        });
}

Summary

Your key takeways from this post should be

Keep your setup simple
Keep your test scope narrow
Observables are manageable with fakeAsync and flush
Be mindful of what you're testing and why

Happy testing!

Python Powered Pipelines? Preposterous!

Stephen Whitmore — Fri, 11 Nov 2022 14:45:40 +0000

No, not preposterous. Powerful.

DevOps is all about rapid delivery. Using Python to make your pipelines "smart" can help you achieve that goal.

Let's say you have a suite of Angular libraries your team created to use for their applications. A robust pipeline for this project will include the following:

validation jobs that make sure
- there's no "fit" or "fdescribe" to narrow down unit tests
- there's no "dist" or ".angular" folders present
- eslint passes
tests
- unit tests
- integration tests
security scans
- npm audit
- SAST scans (SonarQube, Fortify, etc)
publication
- snapshots
- release candidates
- releases

At an enterprise level, you could be dealing with upwards of 20 libraries. You could have a job for each library. Speaking from experience, having jobs for each will quickly turn your pipeline into a big nasty pile of spaghetti. Nobody wants to deal with a big nasty pile of spaghetti.

Worse still, the time it'll take for your pipelines to run will slow things down to an agonizing crawl and have your team pulling their hair out in frustration every time they push a change up.

Or you can have an easy to read and maintain Python script that will figure out which libraries actually changed, then run the jobs for those libraries.

Let's use a mock scenario to illustrate my point. For the sake of brevity we'll just have our pipeline:

Run eslint
Run unit tests
Publish snapshots off of our feature branches

Here's a project that demonstrates this using both GitHub Actions and GitLab CI/CD. I'm including both because I think most people use GitHub Actions but I know many companies also use GitLab for their enterprise applications (plus I'm way more familiar with GitLab CI/CD).

The major points I'll be going over will be:

Setting up a runner image
Setting up your CI file
- GitHub Actions
- GitLab CI/CD
Handling secrets
- Creating an auth token for npmjs.org
- Creating Actions secrets in GitHub
- Creating masked environment variables in GitLab
Pythonizing your pipeline

Setting up a runner image

There are a boat-load of Docker images to choose from for using as your pipeline runner image. Personally, I like having total control over my pipelines and prefer to use my own image. I like Alpine because it's tiny compared to the more popular Ubuntu. Tiny is good because it loads faster and there's a smaller attack surface.

Based on the listed requirements above, our image will need to support Python, the packages our pipeline script will be using, nodejs, and a browser for our unit tests.

Here's a good example of an image that will serve our needs:

FROM alpine:latest

RUN apk add --no-cache --update python3-dev gcc libc-dev libffi-dev git && \
    ln -sf /usr/share/zoneinfo/America/Chicago /etc/localtime && \
    ln -sf python3 /usr/bin/python && \
    ln -sf pip3 /usr/bin/pip

COPY ./scripts/requirements.txt /tmp

RUN python -m ensurepip && \
    python -m pip install --no-cache --upgrade -r /tmp/requirements.txt

RUN apk add --update --repository http://dl-cdn.alpinelinux.org/alpine/v3.16/main nodejs=16.17.1-r0 npm && \
    apk add --no-cache chromium --repository http://dl-cdn.alpinelinux.org/alpine/v3.16/community

ENV CHROME_BIN=/usr/bin/chromium-browser CHROME_PATH=/usr/lib/chromium

Super duper. Assuming you know your way around Docker we can publish our image to whatever registry we use. If you're not familiar with Docker, don't fret. Their documentation is outstanding and well worth spending time reading through.

Setting up your CI file

GitHub Actions

As far as I can tell GitHub doesn't support using a custom pipeline runner image directly. You'll need to wrap a natively supported image around it and set your image as the "container". Kinda icky but it will still serve you.

Disclaimer: I'm still learning my way around GitHub Actions so the below yml file is far from perfect. It works but I'd love to hear about ways it could be improved/optimized.

.github/workflows/ci.yml

name: CI
on: push

jobs:
  CI:
    runs-on: ubuntu-latest
    container: stevewhitmore/nodejs-python

    steps:
      - uses: actions/checkout@v3

      - name: Cache node modules
        id: cache-npm
        uses: actions/cache@v3
        env:
          cache-name: cache-node-modules
        with:
          path: ~/.npm
          key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-build-${{ env.cache-name }}-
            ${{ runner.os }}-build-
            ${{ runner.os }}-

      - name: Allow me to run my script
        run: git config --global safe.directory '*'

      - name: pylint
        run: |
          python -m pylint --version
          PYTHONPATH=${PYTHONPATH}:$(dirname %d) python -m pylint scripts/ci.py

      - name: eslint
        run: python scripts/ci.py eslint

      - name: Unit Tests
        run: python scripts/ci.py unit_tests

      - name: Publish Snapshots
        run: |
          echo "//registry.npmjs.org/:_authToken=${{ secrets.NPM_TOKEN }}" > .npmrc
          python scripts/ci.py publish_snapshots

GitLab CI/CD

.gitlab-ci.yml

image: stevewhitmore/nodejs-python

stages:
  - validation
  - test
  - snapshot

cache:
  key: ${CI_COMMIT_REF_SLUG}
  paths:
    - node_modules/
    - .npm/

pylint:
  stage: validation
  script:
    - python -m pylint --version
    - PYTHONPATH=${PYTHONPATH}:$(dirname %d) python -m pylint scripts/ci.py
  except:
    - tags

eslint:
  stage: validation
  cache:
    key: ${CI_COMMIT_REF_SLUG}
  script:
    - python scripts/ci.py eslint
  except:
    - tags

unit_tests:
  stage: test
  cache:
    key: ${CI_COMMIT_REF_SLUG}
  script:
    - python scripts/ci.py unit_tests
  except:
    - tags

npm_publish_snapshot:
  stage: snapshot
  cache:
    key: ${CI_COMMIT_REF_SLUG}
  script:
    - echo "//registry.npmjs.org/:_authToken=${NPM_TOKEN}" > .npmrc
    - python scripts/ci.py publish_snapshots
  except:
    - main
    - tags

Handling secrets

NPM needs to know where your packages (libraries) will be registered and there needs to be some kind of authentication. It gets this information from the .npmrc file. Assuming you're publishing to npmjs.org, your pipeline's .npmrc file will look pretty similar.

Note: This .npmrc file is created and only exists during the lifecycle of the pipeline job. DON'T use the .npmrc file from your personal workstation!

The NPM_TOKEN is an environment variable we'll pass from the project's settings. Be sure to mask this variable or you'll be inviting the world to publish npm packages on your bahalf. GitHub does this automatically but GitLab requires an additional step.

Creating an auth token for npmjs.org

Sign into npmjs.org and click on your username on the far right. Select "Access Tokens"

Click "Generate New Token" on the far right

Name your token and select the "Automation" option. This is the ideal option because it will bypass two-factor authentication (which you absolutely should have set up).

Copy the token to a file so you don't lose it.

No, you can't use this token. It has been deleted 😉

Creating Actions secrets in GitHub

Go to the project Settings > Secrets > Actions. Click "New repository secret"

Fill out the "Name" and "Secret" keys with NPM_TOKEN and whatever your auth token is, then click "Add secret"

Creating masked environment variables in GitLab

Go to the project Settings > CI/CD
Expand the "Variables" section and click "Add Variable"
Add your auth token to your project. Note the Masked box is checked.

Pythonizing your pipeline

Now for the fun part. Let the Pythonization commence!

Create a folder named "scripts" at the root of your project. In that folder, create a file ci.py.

There was an argument passed in for each Python script call in our CI file. Those arguments in turn are intended to trigger a specific function that will live in the script file.

For example, the unit_tests job has the following line:

python scripts/ci.py unit_tests

We're passing unit_tests to the ci.py file.

scripts/ci.py

import sys

# ...

def unit_tests():
    """Runs unit tests on libraries with changes"""
    npm_command("test")

locals()[sys.argv[1]]()

Let's assume npm_command() handles whatever npm command you pass in (shocking, I know). It would look something like this:

def npm_command(command):
    """Runs npm commands depending on input"""
    npm_install()
    diffs = get_diffs()

    for library in diffs:
        subprocess.check_call(f"npm run {command}-{library}", shell=True)

That get_diffs() function uses the GitPython package to compare the changes on your branch with the default origin branch (main). It finds all the git diffs, plucks out the library name, and returns a set of library names to avoid duplication.

def get_diffs():
    """Gets the git diffs to determine which libraries to run operations on"""
    path = os.getcwd()
    repo = Repo(path)
    repo.remotes.origin.fetch()
    diffs = str(repo.git.diff('origin/main', name_only=True)).splitlines()

    updated_libraries = []

    for diff in diffs:
        if diff.startswith("projects"):
            path_parts = diff.split("/")
            updated_libraries.append(path_parts[1])

    return set(updated_libraries)

Great, but what about something a little more complex, like publishing snapshots? NPM doesn't allow for duplicate version numbers, so how would we handle that?

Let's take another look at that npm_publish_snapshot job.

python scripts/ci.py publish_snapshots

So it'll call the publish_snapshots() function in our script.

def publish_snapshots():
    """Publishes npm snapshots on libraries with changes"""
    npm_command("publish snapshots")

Not super helpful so far. Let's take another look at that npm_command() function.

def npm_command(command):
    """Runs npm commands depending on input"""
    npm_install()
    diffs = get_diffs()

    for library in diffs:
        if command == "publish snapshots":
            handle_snapshot_publication(library)
        else:
            subprocess.check_call(f"npm run {command}-{library}", shell=True)

Now there's an if/else block in our loop. The handle_snapshot_publication() function should append a unique snapshot version to the changed library, build, then publish it.

def handle_snapshot_publication(library):
    """Updates version with snapshot, builds, and publishes snapshot"""
    package_json_path = f"./projects/{library}/package.json"
    with open(package_json_path, "r", encoding="UTF-8") as package_json:
        contents = json.load(package_json)

    version = contents["version"]
    timestamp = datetime.now().strftime("%Y%m%d-%H%M%S")
    is_snapshot_version = re.match("\\s*([\\d.]+)-SNAPSHOT-([\\d-]+)", version)

    if is_snapshot_version:
        version = version.split("-")[0]

    contents["version"] = f"{version}-SNAPSHOT-{timestamp}"
    with open(package_json_path, "w", encoding="UTF-8") as package_json:
        package_json.write(json.dumps(contents, indent=2))

    subprocess.check_call(f"npm run build-{library}", shell=True)
    subprocess.check_call(f"npm publish --access=public ./dist/{library}", shell=True)

The above function reads the changed library's package.json file, parses out the version number, and replaces it with the version number plus a timestamp. So a version 1.2.3 becomes version 1.2.3-SNAPSHOT-{year/month/day-hour/minute/second} (e.g. 1.2.3-SNAPSHOT-20221110-075530). It also has a check in there is_snapshot_version in case you're rerunning a job. This will avoid funky versions from being generated, like 1.2.3-SNAPSHOT-{timestamp}-SNAPSHOT-{timestamp}.

Let's clean that up a little bit to be more singly-minded.

def append_snapshot_version(library):
    """Appends "-SNAPSHOT-" plus timestamp (down to the second) to library version"""
    package_json_path = f"./projects/{library}/package.json"
    with open(package_json_path, "r", encoding="UTF-8") as package_json:
        contents = json.load(package_json)

    version = contents["version"]
    timestamp = datetime.now().strftime("%Y%m%d-%H%M%S")
    is_snapshot_version = re.match("\\s*([\\d.]+)-SNAPSHOT-([\\d-]+)", version)

    if is_snapshot_version:
        version = version.split("-")[0]

    contents["version"] = f"{version}-SNAPSHOT-{timestamp}"
    with open(package_json_path, "w", encoding="UTF-8") as package_json:
        package_json.write(json.dumps(contents, indent=2))

def handle_snapshot_publication(library):
    """Updates version with snapshot, builds, and publishes snapshot"""
    append_snapshot_version(library)
    subprocess.check_call(f"npm run build-{library}", shell=True)
    subprocess.check_call(f"npm publish --access=public ./dist/{library}", shell=True)

By now you should be seeing the pattern. You can see from the job outputs that the pipeline is only running the jobs on the changed libraries:

GitHub

GitLab

Enjoy a less painful pipeline with the power of Python! 🦸‍♂️

State Management Is Easy Now!? An Introduction to Observable Store

Stephen Whitmore — Tue, 25 Oct 2022 04:20:30 +0000

Oh application state. The source of so many bugs. React has Redux, Vue has Pinia, and Angular has NgRx as their most used state management libraries.

NgRx is a great solution for folks well versed in Angular-ese and can make tackling problems with enterprise-sized applications way easier. There's a very big application I work on where we as a team started using NgRx to help us out for this very reason.

I work on a team where most of the developers are hardened Java veterans and don't spend too much time on the frontend. NgRx helped a lot but we still had to deal with reducers, actions, effects, registries, and getting it all wired up properly. As a team we had to understand new concepts and basically adopt an additional framework on top of the framework many of us were already still struggling to learn.

To their credit, the folks behind NgRx have simplified it and have removed a lot of the boilerplate code (there used to be A LOT of boilerplate).

It's much better than trying to manage state without a library by passing around properties from child to parent/parent to child or by using services. I can say from experience that doing so gets very messy very quickly if you have even a moderately complicated application.

In 2020, Dan Wahlin (a big contributor to the Angular community), did a talk about a new library he came up with called Observable Store.

This was game changing and something I don't think got enough attention. Why? Because it's just so dang simple to use and easy to understand.

We just need a basic understanding of RxJS.

That's it!

No, really. Read on and I'll prove it.

To be clear, even though this post is tailored to Angular developers, this is not an Angular-only thing. It can be used with any JS framework - or without, as long as you have RxJS installed.

Even though the documentation is excellent I thought I'd share a starter project and a quick rundown of how it works.

The Rundown

Assuming you have an Angular app set up (and therefore RxJS installed), run the following command:



npm i @codewithdan/observable-store

Create a new class. It'll be treated as a service so it'll have that @Injectable decorator. Extend the ObservableStore class and type it with a model:

customer-store.ts



export interface StoreStateModel {
  customers: CustomerModel[],
  addMode: boolean,
}

@Injectable()
export class CustomersStore extends ObservableStore<StateStoreModel> {
  initialState = {
    customers: [],
    addMode: false,
  };

  constructor() {
    super({
        logStateChanges: true,
    })
    this.setState(this.initialState, 'INIT_STATE');
  }

  get(): Observable<StoreStateModel> {
    const state = this.getState();
    return of(state);
  }
}

Let's pump the breaks for a sec and see where we're at.

We have a class property initialState that gets passed in the constructor to setState() along with the INIT_STATE action. Actions are more for the developers' convenience here and can be any arbitrary string.

We're calling super() since we're extending the ObservableStore class and passing it logStateChanges: true. This prints out the state in the console like so:

That's right. No additional libraries needed. No browser extensions needed. Just a property passed to super(). That's pretty darn super! (Sorry)

Next, we have the get() method that gets that state and wraps it up nice in an Observable.

Now we can inject the CustomersStore into our component and capture the state changes in an Observable class property:

app.component.ts



export class AppComponent {
  state$ = this.customersStore.stateChanged;

  constructor(private customersStore: CustomersStore) {}

So far, so good. But how do we handle getting data? There's a couple different approaches we can take. One would be to add our data service to our CustomersStore, keeping it as the single source of truth and our app nice and clean.

customer-store.ts



export interface StoreStateModel {
  customers: CustomerModel[],
  addMode: boolean,
}

@Injectable()
export class CustomersStore extends ObservableStore<StateStoreModel> {
  initialState = {
    customers: [],
    addMode: false,
  };

  constructor(private dataService: DataService) {
    super({
        logStateChanges: true,
    })
    this.setState(this.initialState, 'INIT_STATE');
  }

  get(): Observable<StoreStateModel> {
    const state = this.getState();
    return of(state);
  }

  fetchData(): void {
    this.fetchSub = this.dataService.getData()
      .subscribe({
        next: (customers: CustomerModel[]) => {
          const updatedState = {
            ...this.initialState,
            customers,
          }
          this.setState(updatedState, 'FETCHED_DATA');
        },
        error: response => // do stuff to handle error
      });
  }
}

Back in our AppComponent we can fetch it in the ngOnInit hook.

app.component.ts



export class AppComponent implements OnInit {
  state$ = this.customersStore.stateChanged;

  constructor(private customersStore: CustomersStore) {}

  ngOnInit(): void {
    this.getCustomerData();
  }

  getCustomerData(): void {
    this.customersStore.fetchData();
  }

I try to avoid putting logic directly in lifecycle hooks. I think it makes unit tests easier to write and the code easier to read.

Now our console output looks like this:

Great, but what about updating the state with new customers?

Let's take a look!

We should probably display our customers in its own component to keep our components nice and single-minded.

Let's update the AppComponent's html to pass the state to our new component:

app.component.html



<div *ngIf="state$ | async as state">
    <app-customers [state]="state"></app-customers>
</div>

customers.component.ts



export class CustomersComponent implements OnChanges {
  @Input() state: StoreStateModel = { customers: [], addMode: false };
  customersData: CustomerModel[] = [];
  customersStore: CustomersStore;
  displayedColumns: string[] = ['id', 'firstName', 'lastName', 'phone', 'email', 'memberSince', 'delete'];

  constructor(customersStore: CustomersStore) {
    this.customersStore = customersStore;
  }

  ngOnChanges(changes: SimpleChanges): void {
    const stateChanges = changes['state'];
    if (stateChanges && stateChanges.currentValue) {
      this.customersData = stateChanges.currentValue.customers;
    }
  }

Our customersStore was injected as a public property so we can directly call initAddMode() in the html.

customers.component.html



<!-- a table or something to display the data -->

<button
    class="addBtn"
    (click)="customersStore.initAddMode()"
    [disabled]="state.addMode">
    Add
</button>

customers-store.ts



initAddMode(): void {
  const state = this.getState();

  const updatedState = {
    ...state,
    addMode: true
  };

  this.setState(updatedState, 'INIT_ADD_MODE');
}

Let's assume you have another component AddCustomerComponent and you have its selector in the CustomersComponent's html:



<div *ngIf="state.addMode">
    <app-add-customer></app-add-customer>
</div>

AddCustomerComponent would look something like this:

add-customer.component.ts



export class AddCustomerComponent {
  customersStore: CustomersStore;
  addCustomerForm = this.fb.group({
    firstName: ['', Validators.required],
    lastName: ['', Validators.required],
    phone: ['', Validators.required],
    email: ['', Validators.required],
  })

  constructor(
    private fb: FormBuilder,
    customersStore: CustomersStore,
  ) {
    this.customersStore = customersStore;
  }
}

Like with the CustomersComponent we injected customersStore as a public property so we can directly call addCustomer() and resetView() in the html.



<!-- form stuff -->
<div class="button-group">
  <button
    type="submit"
    [disabled]="!addCustomerForm.valid"
    (click)="customersStore.addCustomer(addCustomerForm.value)">
    Save
  </button>
  <button
    type="button"
    (click)="customersStore.resetView()">
    Cancel
  </button>

customers-store.ts



addCustomer(customer: CustomerModel): void {
  const state = this.getState();
  const ids = state.customers.map(c => c.id)
  const newId = ids.length ? Math.max(...ids) + 1 : 1;
  customer.id =  newId;
  customer.memberSince = new Date();

  this.addSub = this.dataService.addCustomer(customer)
    .subscribe({
      next: (customers: CustomerModel[]) => {
      const updatedState = {
        customers: [ ...state.customers, customer ],
        addMode: false,
      };

      this.setState(updatedState, 'ADDED_CUSTOMER');
    }, 
    error: response => // do stuff to handle error
  });

}

resetView(): void {
  const state = this.getState();

  const updatedState = {
    ...state,
    addMode: false,
  };

  this.setState(updatedState, 'RESET_VIEW');
}

By now you should be getting the idea. For a more in-depth example feel free to take a peek at that example project I mentioned earlier.

Bonus! Unit Tests

Unit testing Observable Store is pretty straight forward. After all, we're just dealing with RxJS and class methods.

Yes, I write my tests after I write my application code. Yes, I know it's better to write tests first and then write application code. I fully embrace unit tests (as should you as a professional) but I haven't quite made the mental switch to TDD. I'll get there, promise.

Let's start off with creating some mock data and a stub for our DataService:

customers-store.spec.ts



const mockData = require('../../test-data/customers.json');
const dataServiceStub = {
    getData: () => of([]),
}

Next, the setup. Just like with any other service we'll want to inject this class into the TestBed:

customers-store.spec.ts



describe('CustomersStore', () => {
  let customersStore: CustomersStore;

  beforeEach(() => {
    TestBed.configureTestingModule({
      providers: [ 
        CustomersStore,
        { provide: DataService, useValue: dataServiceStub }
       ],
    });

    customersStore = TestBed.inject(CustomersStore);
  });

Now we test the class like we would any other component:



describe('addCustomer()', () => {
  it('should set the ID to 1 if no customers are present', fakeAsync(() => {
    customersStore.addCustomer(mockData[0]);

    customersStore.get()
      .subscribe({
        next: data => {
          expect(data.customers[0].id).toBe(1);
        }
       });
  }));

  it('should set the ID to 1 more than the last one', fakeAsync(() => {
    customersStore.addCustomer(mockData[0]);
    customersStore.addCustomer(mockData[1]);

    customersStore.get()
      .subscribe({
        next: data => {
          expect(data.customers[1].id).toBe(2);
        }
    });
  }));

  it('should set the "memberSince" property to today\'s date', fakeAsync(() => {
    customersStore.addCustomer(mockData[0]);

    customersStore.get()
      .subscribe({
        next: data => {
          expect(data.customers[0].memberSince).toEqual(new Date());
        }
      });
  }));
});

That's all folks! I'm curious to hear your thoughts or experiences with Observable Store. Let me know!

Take Your WordPress Site Farther With Angular

Stephen Whitmore — Sat, 22 Oct 2022 07:12:51 +0000

TL;DR

You can create a micro frontend with Angular and dress it up like a WordPress plugin. Here's a working example of what I'm talking about - https://github.com/stevewhitmore/angular-wordpress-integration-starter

Background

At the risk of sounding like I'm recycling an old post of mine, I wanted to give a quick tutorial on how you can use Angular to add custom business logic to the frontend of your WordPress app.

There was a time when Angular bundles were large. Too large to consider doing something like inserting an Angular app into a WordPress site. Back when I wrote about doing this with Vue.js I wasn't aware of just how small these bundles had become at that point, in large part due to the new(ish) Ivy compilation engine the Angular team rolled out with version 9.

As of this writing the latest stable version of Angular is 14.2.7. The bundle size for a freshly generated Angular app with no routing included or any other kind of extra optimization is roughly 180kb. For WordPress installations this is a small drop in the bucket, and well worth the benefits available to you.

So, if you have need of adding highly interactive, complicated business logic to your WordPress app then read on.

Step 1: Make the Angular app

Assuming you have npm installed already, install the Angular CLI



npm i -g @angular/cli

Once that's done create the Angular project.



ng new my-awesome-new-app

Follow the prompts to get your app generated. You wont likely need routing if you're embedding it into a page of your WordPress app. Using Sass or SCSS isn't a bad idea but isn't strictly necessary. Using either wont meaningfully impact the size of your bundle.

Now you can work on the application outside of WordPress. It should not be tightly coupled to your WordPress app and therefore should work the same independently.

Step 2: Folder Restructuring

The Angular CLI will generate some files that are not really required. You can safely remove the following: .browserlistrc, .editorconfig, package-lock.json, .vscode.

Create a new folder named app from the root of your newly created Angular project. Put everything from the root of your project into the app folder.

Next, make a new folder called plugin and another folder with the same name of whatever your new WordPress plugin will be called. In my case it's my-awesome-new-app.

Finally, move the .git, .gitignore, and README.md files from your newly created app folder to the root of your project.

Your folder structure will look something like this:



|-- app
    |-- [+] node_modules
    |-- [+] src
    |-- angular.json
    |-- karma.conf.js
    |-- package.json
    |-- tsconfig.app.json
    |-- tsconfig.json
    |-- tsconfig.spec.json
|-- plugin
    |-- my-awesome-new-app
|-- [+] .git
|-- .gitignore
|-- README.md

Step 3: Create the Plugin File

Create a new php file in your /plugin/my-awesome-new-app folder. You'll want the php file name to be the same as the folder name so WordPress knows where to find the plugin file. At this point your folder structure should look like this:



|-- app
    |-- [+] node_modules
    |-- [+] src
    |-- angular.json
    |-- karma.conf.js
    |-- package.json
    |-- tsconfig.app.json
    |-- tsconfig.json
    |-- tsconfig.spec.json
|-- plugin
    |-- my-awesome-new-app
        |-- my-aweseome-new-app.php
|-- [+] .git
|-- .gitignore
|-- README.md

Now you'll want to fill the new php file with code that

provides metadata about the plugin through the comments at the top of the file
registers and enqueues the styles and minified javascript for the Angular app
creates a shortcode to insert into your WordPress site

It'll look something like this:



<?php
/**
 * Plugin Name:         My Awesome New App
 * Plugin URI:          https://yourdomain/wherever-you-keep-the-app-readme-file
 * Description:         Some great app that I made and it's so great it'll make your life great!
 * Version:             1.0.0
 * Author:              Steve Whitmore
 * Author URI:          https://stevewhitmore.dev
 * 
 * Be sure to rename the folder this file is in and this file to match what your plugin will be called. The names must be the same so WordPress knows where to look.
 */

function load_ng_scripts() {
    wp_enqueue_style( 'ng_styles', plugin_dir_url( __FILE__ ) . 'dist/my-awesome-new-app/styles.somehash.css' );
    wp_register_script( 'ng_main', plugin_dir_url( __FILE__ ) . 'dist/my-awesome-new-app/main.somehash.js', true );
    wp_register_script( 'ng_polyfills', plugin_dir_url( __FILE__ ) . 'dist/my-awesome-new-app/polyfills.somehash.js', true );
    wp_register_script( 'ng_runtime', plugin_dir_url( __FILE__ ) . 'dist/my-awesome-new-app/runtime.somehash.js', true );
}

add_action( 'wp_enqueue_scripts', 'load_ng_scripts' );

function attach_ng() {
    wp_enqueue_script( 'ng_main' );
    wp_enqueue_script( 'ng_polyfills' );
    wp_enqueue_script( 'ng_runtime' );

    return "<app-root></app-root>";
}

add_shortcode( 'ng_wp', 'attach_ng' );

// Add the shortcode [ng_wp] to any page or post.
// The shorcode can be whatever. [ng_wp] is just an example.
?>

Step 4: Change the NPM Build Script

You're nearly there. We do need to account for a couple things.

Your php file needs to be able to find the minified js and css files Angular outputs when it builds.
Angular likes to throw a hash in the js and css file names to help with caching issues.

The first issue is easy enough to deal with.

The plugin will need to have a copy of the executables for this app so we'll update the build script in our package.json file to do the extra step of copying the dist folder to our new plugin folder.

That means



"build": "ng build"

becomes



"build": "ng build && cp -r ./dist ../plugin/my-awesome-new-app"

Easy peasy, right? Unfortunately we're not quite there yet. Those files in the php example above with "somehash" in their name was not a typo. I put that placeholder there because every time changes are made to your Angular app, the CLI will generate new names for them to prevent browser caching. They all start the same but have some jumbled mess (a hash) between the prefix and their file types. So dist/my-awesome-new-app/main.somehash.js really looks something like dist/my-awesome-new-app/main.14089c95b00767cf.js.

We'll need to create a small script that will copy the names of the minified js and css files to the php file. Luckily I went ahead and did this for you to save some time:

build.js



const { execSync } = require('child_process');
const fs = require('fs');
const pluginName = 'my-awesome-new-app';
const pluginFileName = `${pluginName}.php`;
const destination = `../plugin/${pluginName}`;
const pluginFilePath = `${destination}/${pluginName}.php`

// Remove the dist folder in the plugin file if its present. Doesn't care if it's not.
fs.rmSync(`${destination}/dist`, { recursive: true, force: true });

// Run the build command
execSync('ng build --configuration production', { encoding: 'utf-8', stdio: 'inherit' });

// Move the bundle from the `/app` folder to the plugin's folder
execSync(`mv ./dist ${destination}`)

// copy the js and css file names to an array
distFilenames = fs.readdirSync(`${destination}/dist/my-awesome-new-app`);
scriptsAndStyleFiles = distFilenames.filter(file => file.endsWith('.js') || file.endsWith('.css'));

// replace the js and css file names in the php file contents
const pluginFileContents = fs.readFileSync(`${pluginFilePath}`, 'utf8');

const updateLine = (line, name) => {
    const matchedLinePart = line.match(/(?<=app\/).*?(?=\')/gs).toString();
    const matchedFileName = scriptsAndStyleFiles.find(file => file.includes(name));
    return line.replace(matchedLinePart, matchedFileName);
}

const updatedFileContentArray = pluginFileContents.split(/\r?\n/).map(line => {
    switch (true) {
        case line.includes('wp_enqueue_style( \'ng_styles'):
            return updateLine(line, 'styles');
        case line.includes('wp_register_script( \'ng_main'):
            return updateLine(line, 'main');
        case line.includes('wp_register_script( \'ng_polyfills'):
            return updateLine(line, 'polyfills');
        case line.includes('wp_register_script( \'ng_runtime'):
            return updateLine(line, 'runtime');
        default:
            return line;
    }
});
const updatedFileContents = updatedFileContentArray.join('\n');

// write the new names to the php file
fs.writeFileSync(`${pluginFilePath}`, updatedFileContents);
console.log(`*************** ${pluginFileName} updated! ***************`)

Go back to your /app/package.json file and change that build script to look like this:



"build": "node ./build.js"

Run npm run build from your /app folder.

The final folder structure should look like this:



|-- app
    |-- [+] node_modules
    |-- [+] src
    |-- angular.json
    |-- build.js
    |-- karma.conf.js
    |-- package.json
    |-- tsconfig.app.json
    |-- tsconfig.json
    |-- tsconfig.spec.json
|-- plugin
    |-- my-awesome-new-app
        |-- [+] dist
        |-- my-aweseome-new-app.php
|-- [+] .git
|-- .gitignore
|-- README.md

Step 5: Upload and Activate

Upload the contents of /plugin/ to your WordPress installation's /wp-content/plugins folder. Log into your WordPress admin panel and navigate to the Plugins section. You should see your new plugin waiting to be activated.

Step 6: Insert the Shortcode

Once activated you can either insert the shortcode through template code or by adding it to a page



<?php
/**
 *
 * Template name: Some Template
 *
 */
get_header(); ?>

<section id="main">
    <h2>Some Page About Something Or Other</h2>
    <?php echo do_shortcode("[ng_wp]"); ?>
</section>

<?php get_footer(); ?>

Step 7: Celebrate

Woohoo! We did it! Let me know if you run into any issues or have any questions. You can find an example project that followed all of these steps already here. Happy coding!

Take Your WordPress Site Further With Vue.js

Stephen Whitmore — Tue, 09 Mar 2021 05:18:59 +0000

TL;DR

A 5 minute read? Who has time for that amiright? You can create a microservice with Vue.js and dress it up like a WordPress plugin. Here's a working example of what I'm talking about - https://github.com/stevewhitmore/vue-wordpress-integration-starter

Background

I recently came across a situation where I had to add some fairly advanced frontend functionality to a WordPress website that I manage. I had a couple options that came to mind right away:

Create a custom theme template and shoehorn some jQuery in there to get the job done.
Find a plugin that does something similar and shoehorn some jQuery in there to get the job done.
Do either option 1 or 2 but with vanilla JS because even though it's installed by default for WordPress you really don't need jQuery anymore.

In my experience choosing one of these three options is usually how custom functionality gets added to an otherwise established WordPress installation/theme.

Options 1 and 2 are out the window for me by default nowadays but unfortunately option 3 doesn't work so well when you have a custom business need and complicated logic that goes into the functionality. Applications written in vanilla JS don't scale super well which is why we have frameworks like Angular, React, and Vue among others.

Fortunately for us Vue plays very nicely with existing JavaScript code. I realized I could create a microservice in Vue and drop it into my WordPress installation as a plugin.

Surely someone else has had this same exact need as me, I thought. I'll find something on DEV.to or Medium or something where somebody figured this out already and I'll just piggyback off of that. Well past me soon found out how wrong he was. Yes there was some documentation out there but I couldn't find anything where somebody laid out everything for me step by step. Sometimes I like figuring things out. Sometimes I don't have the time, motivation, or energy for such tomfoolery. I'm lazy by nature and in most cases being lazy works to our advantage as developers.

I didn't have the luxury of being lazy in this scenario and I had to piece it together. That is why, dear reader, I extend to you this gift of not-having-to-because-the-answer-is-out-there-already. You're welcome.

Step 1: Make the Vue app

A good microservice is decoupled from the code it interacts with. Create a new Vue app outside of your WordPress codebase. I really like their CLI feature so I'd recommend getting that installed if you don't have it already.



npm i -g @vue/cli

Once that's successfully done you'll want to create the Vue project.



vue create my-awesome-new-app

Follow the prompts and get a basic placeholder app generated. This article isn't really about how to create a Vue app via their CLI but their docs are pretty helpful with this topic.

Now you can work on developing the application outside of WordPress and get it working independently. Once it's in a place where you want to start pulling it into your WordPress site you can move onto the next step.

Step 2: Do a Bit of Folder Restructuring

From the root of your newly created Vue project create another folder called app. Put everything from the root of your project in that folder. Next make two new folders: plugin and inside that whatever the name of your app is. In my case it's plugin/my-awesome-new-app. It should look something like this:

Step 3: Modify the build script

We're making this app a WordPress plugin. That plugin needs to have a copy of the executables for this app so we'll update the build script in our package.json file to do the extra step of copying the dist folder to our new plugin folder.



"build": "vue-cli-service build",

becomes



"build": "vue-cli-service build && cp -r ./dist ../plugin/my-awesome-new-app",

Now when you run npm run build you'll see something like the following:

So now you've got the following contents in your project:



|-- app
    |-- [+] dist
    |-- [+] node_modules
    |-- [+] public
    |-- [+] src
    |-- .gitignore
    |-- babel.config.js
    |-- package-lock.json
    |-- package.json
    |-- README.md
|-- plugin
    |-- my-awesome-new-app
        |-- [+] dist

Step 4: Create the Plugin File

Now comes the part where we meld our shiny new Vue app into a WordPress plugin. Create a php file in your /plugin/my-aweseome-new-app folder. You'll want the file name to be the same as the plugin. In this case it's my-awesome-new-app.php. Here's a revised version of the folder structure table above:



|-- app
    |-- [+] dist
    |-- [+] node_modules
    |-- [+] public
    |-- [+] src
    |-- .gitignore
    |-- babel.config.js
    |-- package-lock.json
    |-- package.json
    |-- README.md
|-- plugin
    |-- my-awesome-new-app
        |-- [+] dist
        |-- my-awesome-new-app.php

Now you'll want to fill out the new php file with code that

Provides metadata about the plugin through the comments at the top of the file
Registers and enqueues the styles and minified javascript for the Vue app
Creates a shortcode to insert into your WordPress site

It'll look something like this -



<?php
/**
 * Plugin Name:         My Awesome New App
 * Plugin URI:          https://yourdomain/wherever-you-keep-the-app-readme-file
 * Description:         Some great app that I made and it's so great it'll make your life great!
 * Version:             1.0.0
 * Author:              Steve Whitmore
 * Author URI:          https://stevewhitmore.gitlab.io 
 * 
 * Be sure to rename the folder this file is in and this file to match what your plugin will be called. The names must be the same so WordPress knows where to look.
 */

function load_vuescripts() {
    wp_enqueue_style( 'vue_wp_styles', plugin_dir_url( __FILE__ ) . 'dist/css/app.2cf79ad6.css' );
    wp_register_script( 'vue_wp_compiled', plugin_dir_url( __FILE__ ) . 'dist/js/app.010d7631.js', true );
    wp_register_script( 'vue_wp_dependencies', plugin_dir_url( __FILE__ ) . 'dist/js/chunk-vendors.1be0eeb0.js', true );
}

add_action( 'wp_enqueue_scripts', 'load_vuescripts' );

function attach_vue() {
    wp_enqueue_script( 'vue_wp_compiled' );
    wp_enqueue_script( 'vue_wp_dependencies' );

    return "<div id='app'></div>";
}

add_shortcode( 'vue_wp', 'attach_vue' );

// Add the shortcode [vue_wp] to any page or post.
// The shorcode can be whatever. [vue_wp] is just an example.
?>

Note: Each time you make changes to your Vue app and build, the files will have newly hashed file names to help with caching issues. Be sure to update your php file with the new file names every time you build as needed to see your changes reflected.

Step 5: Upload and Activate

Step 6: Insert the Shortcode

Once activated you can either insert the shortcode through template code or by adding it to a page



<?php
/**
 *
 * Template name: Some Template
 *
 */
get_header(); ?>

<section id="main">
    <h2>Some Page About Something Or Other</h2>
    <?php echo do_shortcode("[vue_wp]"); ?>
</section>

<?php get_footer(); ?>

Step 7: Rejoice

You did it!

That wasn't so bad was it? If it was please feel free to let me know how I can make this tutorial easier to follow and I'll get it updated. Otherwise please don't hesitate to ask me any questions!

A fun exercise for new web developers

Stephen Whitmore — Sat, 10 Oct 2020 05:10:13 +0000

Are you a new developer eager to find useful ways to utilize your newly discovered superpowers? One idea is to set your browser's home page to a custom one.

For example, I use Firefox mostly to listen to white noise or music while working. I created the following page and set it as my Firefox home page -

<!DOCTYPE html>
<html>
<head>
    <meta charset='utf-8'>
    <title>home</title>
    <style>
        * {
            margin: 0;
        }
        div {
            display: flex;
            height: 100vh;
        }
        a {
            display: flex;
            align-items: center;
            justify-content: center;
            flex: 1;
            text-decoration: none;
            font-size: 20px;
            color: #fff;
            box-sizing: border-box;
            transition: font-size 0.5s ease;
        }
        a:hover {
            font-size: 2em;
        }
        a:first-child {
            background-color: #333;
        }
        a:nth-child(2) {
            background-color: #006fff;
        }
    </style>
</head>
<body>
    <div>
        <a href="http://asoftmurmur.com">asoftmurmur</a>
        <a href="https://pandora.com">pandora</a>
    </div>
</body>
</html>

Save the html file somewhere and navigate to it in your file explorer. Right click on the file and open with any browser.

The URL in the address bar will be the path to your html file prefixed by file://. In my case it's file:///home/swhitmore/.mozilla/ffhome.html.

Set your browser's home page to this new URL and voilà you have a new custom home page!

Not sure how to set the browser's home page? Mozilla has documentation for Firefox and Google has some for Chrome was well.