DEV Community: Alexis Reigel

Share to PWA from mobile

Alexis Reigel — Wed, 10 Jul 2024 18:35:37 +0000

If you have a website that can be installed as a PWA on your mobile device it has also the ability to receive data from the "share to" functionality on mobile phones. Depending on what you're trying to do you don't need to create a native app.

This article shows how I made use of this for unnote.

There are 3 things that are needed as part of your application to make this work:

Update your manifest to support "share to"
Handle the "share to" request in your service worker
Handle the shared data in your app

Let's go through each part in some detail.

1. Manifest

You need to add a new entry share_target to your manfest.json. The following manifest allows any text data and all types of images to be sent to your application.

"share_target": {
  "action": "/share-target/",
  "method": "POST",
  "enctype": "multipart/form-data",
  "params": {
    "title": "title",
    "text": "text",
    "url": "url",
    "files": [
      {
        "name": "image",
        "accept": ["image/*"]
      }
    ]
  }
}

action is the URL that will receive the data. This will be explained in the next chapter about the service worker.
params represent the different ways the mobile phone sends the data
1. title is provided when a document is shared
2. text contains the contents of the shared document
3. url is provided when a resource with a URL (as e.g. a website) is shared
4. files is provded when a binary file is shared. The definition accepts an array of mimetypes that your aplication should accept.

Depending on what data your application should be able to receive you don't need to configure all the params. files is only needed when you want to support binary data.

2. Service Worker

The following is a minimal service worker that intercepts the URL /share-target/ which was previously configured in the manifest. It then puts the data in the caches, which is a global CacheStorage in the browser.

self.addEventListener('fetch', (event) => {
  if (event.request.url.endsWith('/share-target/') && event.request.method === 'POST') {
    return event.respondWith(
      (async () => {
        const formData = await event.request.formData();
        const image = formData.get('image');
        const title = formData.get('title');
        const text = formData.get('text');
        const url = formData.get('url');

        const cache = await caches.open('media');

        if (image) {
          await cache.put('shared-image', new Response(image));
        } else {
          await cache.put('shared-data', new Response(JSON.stringify({ title, text, url })));
        }
        return Response.redirect('/#/handle-share-target', 303);
      })(),
    );
  }
});

The service worker handles images and text data differently, and uses two separate cache keys. The text data is stored as JSON, while the image is stored as a Response.

Note that the intercepted request won't make it to your server. The last statement makes a client side redirect to where your application will actually handle the received data.

3. Application

The last part is the actual application fetching the data from the cache and doing whatever you want to do with it. The following two functions are helpers to extract the json data and the binary image data from the cache.

export async function getBlob(name) {
  const cache = await caches.open('media')

  const image = await cache.match(name)
  if (image) {
    const blob = await image.blob()
    await cache.delete(name)

    return blob
  }
}

export async function getJson(name) {
  const cache = await caches.open('media')

  const data = await cache.match(name)
  if (data) {
    const json = await data.json()
    await cache.delete(name)

    return json
  }
}

The next part is the application specific part. The following shows how to use the previous functions to retrieve the data.

const blob = await getBlob('shared-image')

You could e.g. convert the blob to an image or resize the image.

The last piece of code shows how to extract the properties from the cached JSON.

const { title, text, url }  = await getJson('shared-data')

Git cleanup-branches

Alexis Reigel — Mon, 11 Jul 2022 17:21:00 +0000

Additionally to the existing git squash and git fixup I added another piece in my custom git toolbox fitting in with the git fixup workflow:

git cleanup-branches

This one is especially useful if you work in a team and work with pull / merge requests, and need to once in a while clean up the branches in your local repository.

The script consists of 3 steps:

Prune remote branches This means that all branches which don't exist in the remote repository anymore are also deleted locally
Remove merged branches Branches that have been merged to the default branch (i.e. main or master) are deleted. This is useful if you previously merged a PR / MR.
Remove branches from other authors This step removes branches that don't have any commits by you. This usually happens when you checked out a branch by someone else, possibly to review their work.

A sample session could look like this:

 ~/src/example ⑂ main ? = ➜ git cleanup-branches
No local changes to save
Already on 'main'
Your branch is up to date with 'origin/main'.
🥁 Pruning remote branches...
Fetching origin
From github.com:koffeinfrei/example
 - [deleted]            (none)    -> origin/fix/weird-stuff
 - [deleted]            (none)    -> origin/feat/nice-stuff

🥁 Removing merged branches...
Deleted branch feature/feat/nice-stuff (was fee237764).

🥁 Removing branches from other authors...
You don't seem to have any commits in the branch ⑂ feature/docs/add-deployment-section

 * 91e8d233a 2022-07-05 Document deployment (feature/docs/prompt-for-sw-updates) [Gob Bluth]

Delete the branch 'feature/docs/prompt-for-sw-updates'? (y/n)? y
Deleted branch feature/docs/prompt-for-sw-updates (was 91e8d233a).

Already on 'main'
Your branch is up to date with 'origin/main'.

The source code is available on GitHub.

Easy tmux session setup

Alexis Reigel — Tue, 17 Aug 2021 16:25:58 +0000

Original post:

www.koffeinfrei.org/2021/08/14/easy-tmux-session-setup

For development I need a certain tmux setup, which I don't want to kick off every time manually. I used to use Tmuxinator to manage my tmux session setup. For mainly two reasons I switched away from it though. To be clear, none of them are the tools' fault.

I don't need a per project setup
My setup is fairly simple, which doesn't really justify the dependency

What I now have is a bash script that sets up my tmux session with all the windows and split panes bootstrapped and tools running that I usually need. Since my setup isn't very complicated using tmux commands is enough and I don't need the declarative yaml structure that Tmuxinator provides.

This is my annotated tmux-dev script:



#!/usr/bin/env bash

# Create a tmux session
tmux new-session -d

# Start vim in the first window
tmux send-keys 'vim' C-m

# Create a 2nd window
tmux new-window

# Create a horizontal split in the 2nd window, with 75% / 25% width distribution
tmux split-window -h -p 25

# Start `git watch-status` in the right split
tmux send-keys 'git watch-status' C-m

# Split the right split vertically
tmux split-window -v

# Start `git watch-log` in the right bottom split
tmux send-keys 'git watch-log' C-m

# Focus the left split pane
tmux select-pane -t 0

# Create a 3rd window, without running a command
tmux new-window

# Go to the 1st window (vim) and put the focus on it
tmux select-window -t 0
tmux select-pane -t 0

# Attach the session. Ready to start hacking
tmux -2 attach-session -d

This is what the tmux session from the above script looks like:

The most important commands to define the setup are the following:

new-window: Create a new window
split-window -h: Create a horizontal split pane
split-window -v: Create a vertical split pane
send-keys: Execute a command, i.e. start a program

Why you need to see your test fail

Alexis Reigel — Tue, 09 Apr 2019 16:18:05 +0000

Original post:

www.koffeinfrei.org/2019/04/07/why-you-need-to-see-your-test-fail

Red / green (/ refactor)

When developing using TDD or test-first the first step is to write a test. This test will initially fail, because there isn’t an implementation yet.

A test-first workflow implicitly ensures that a test is failing before turning green. Read up on the The Cycles of TDD if you’re not familiar with it.

When writing a test after writing the production code you’ll never see the test fail, because the correct implementation is already there.

So? What’s the problem with this?

The problem is that if you never see your test fail you don’t know if your test is actually testing the right thing, or testing anything at all.

The main purpose of a test is to make sure that your code is working properly. (If you’re doing TDD, driving the design of your production code actually is the main purpose of writing a test.)

If you don’t know if your code is actually testing the right thing, you can’t have confidence in your test, and you can’t have confidence in your production code.

If you ever write a test after, you need to temporarily change the implementation to see your test fail. Don’t change the test, change the production code.

Real life example

Say we want to fix a bug. Before fixing it, we create a test that asserts that the bug exists in the first place. This means that the test needs to fail. We are at an equivalent as the first step in the TDD cycle.

Only after writing the test we fix the bug. After fixing the bug, the test goes green.

Imagine we write the test after fixing the bug. How do we know that the test actually tests that the bug does not exist anymore? Worst case is that we haven’t actually fixed the bug.

To make sure that we actually have, we need to undo the fix, run the test and make sure that the test fails. By doing that we verify that the bug has an effect on our test that represents the expected behaviour of our production code.

When re-applying the fix and the test goes green we can be pretty confident that we are testing the bug fix, and thus that the bug does not exist anymore (at least not in the form that our test case covers).

The bottom line

If you want to trust your code you need to be able to trust your tests. You can’t do that unless you’ve seen your tests fail.

So don’t get lazy. Don’t just assume that your test is fine. See. it. fail.

Private methods are a code smell

Alexis Reigel — Tue, 12 Feb 2019 13:51:11 +0000

Original post:

www.koffeinfrei.org/2019/02/09/private-methods-are-a-code-smell

Just to get it out of the way up front: I'm not saying you should never use private methods.

I'm trying to convey something a bit more nuanced. If you aren't a person that can appreciate the grey zones of life this blog post may not be for you. Or maybe even so. You should decide for yourself. If you can't do that, then this blog post may not be for you. Or maybe it is nevertheless… Let's do this.

Your private is someone else's public

The bottom line is that a private method of one class could be a public method of another class. Every functionality is a public interface of something.

If it has to be made private this usually means that it is in the wrong place, i.e. in the wrong class.

Don't violate the SRP

Making a method private often means this: "This method doesn't really belong in this class, so I'll just make it private so nobody notices." It's just sweeping the dirt under the carpet. Just clean your floor properly and move this method out of that class.

Private methods should not be tested

I believe that private methods should not be tested, even if your language supports calling them. Tests should only verify the public interface of a class. A private method is an internal implementation detail which may change and thus will break the test.

If the functionality of a private method is trivial it may be fine not to explicitly test it. If it is non trivial though, testing the behavior of a class’s private methods indirectly through the class’s public methods is pretty much the same as testing it directly. If the private method has a complexity that should be under test, it should be public. If it doesn't make sense to be public in that class, it should be moved to another class.

If your goal is to achieve high test coverage, everything should be public and therefore testable.

Public interfaces should only expose what's relevant

The consumer of a public interface should not be bothered with unnecessary internals. A method that does not seem to belong to the public interface usually does not have any business of being part of that class and should usually be moved somewhere else.

Did you say reusability?

Having private methods excludes that functionality from being reused. If that functionality is moved to a public method though it can be consumed by someone else as well.

Internal helper methods are (probably) fine

There are cases where a private method is fine. If a method is really just a helper for a public method and doesn't make sense to live on its own in another context then it's fine to keep it as a private method. If you start to touch any of the guidelines mentioned before, this private method may evolve though from being private.

An example

This is just a really trivial academic example, but it should be enough to illustrate my point:

class Car
  def start
    ignite
  end

  private

  # Is ignition the responsibility of the `Car`?
  # Or rather of the motor?
  def ignite
  end
end

Let's move the private method to the Motor class:

class Car
  attr_accessor :motor

  def start
    motor.ignite
  end
end

class Motor
  def ignite
  end
end

The "private" story here is this:

The car starts by igniting itself

The car starts by igniting the motor itself

The refactored story on the other hand is this:

The car starts by telling the motor to ignite

4 questions to get private methods out of your face

If the answer to any of the following questions is "yes" you should consider extracting the private method:

Does this method violate the SRP?
Should I test this method?
Is this method relevant as part of the public interface?
Could this method be reused and be consumed by another class as well?

Perfection is never achieved

Having no private methods at all is the result of a perfect software design. This doesn't imply that we cannot use private methods at all. It means that we should try and strive towards a perfect design and reduce the use of private to a minimum.

The Git fixup workflow

Alexis Reigel — Sat, 29 Sep 2018 19:04:59 +0000

Original post:

www.koffeinfrei.org/2018/09/18/the-git-fixup-workflow/

Introduction

The GitHub flow, or a similar Git strategy where the main work is done on feature branches which result in pull or merge requests, has become the standard way to work with Git and GitHub or GitLab (or Bitbucket even) for many developer teams. Besides the main advantages of this way of working it also enables developers to keep a clean Git history (see also 5 rules to Git better).

Let's assume the following as a starting point for the suggested workflow in this post:

You want to maintain a clean Git history, meaning that fix commits should be avoided
You don't want to interrupt your development workflow by having to rewrite your Git history all the time
You can use git commit --amend only for the latest commit

Git has some powerful commands that allow us to both keep a clean history and not having to interrupt our development workflow. We'll call it "the Git fixup workflow".

The linear workflow

To illustrate the Git fixup workflow, we'll use the following example hack session:

# coding the user component's index view

$ git commit -m "add user component's index view"

# coding the user component's edit view

$ git commit -m "add user component's edit view"

# updating the component's index view so it actually works

$ git commit -m "add user component's index view, it works now"

# a typo is noticed in the index view

$ git commit -m "fix typo in index view"

# fix a bug in the view rendering

$ git commit -m "fix view rendering"

$ rubocop
$ yarn lint

# fix linting errors

$ git commit -m "fix linting errors"

# team members do a code review on the PR / MR

$ git commit -m "fix import in index"

The above session leads to the following Git history:

fix import in index
fix linting errors
fix view rendering
fix typo in index view
add user component's index view, it works now
add user component's edit view
add user component's index view

The following commits reflect the actual work that's relevant from another developer's standpoint:

fix view rendering
add user component's edit view
add user component's index view

All commits that amend a previous commit just clutter the history and should be squashed. The commit "fix typo in index view" for example should be squashed together with "add user component's index view".

To clean up the history, we could manually interactively rebase the commits before merging the branch. Imagine though that you may have many commits and later in the process, you won't remember which ones should be squashed together. Also, it's a lot of manual work to mark the relevant commits in the interactive rebase mode.

The fixup workflow

Git includes everything required to automate this. So let's redo the previous hack session with our new toolset:

# coding the user component's index view

$ git commit -m "add user component's index view"

# coding the user component's edit view

$ git commit -m "add user component's edit view"

# updating the component's index view so it actually works

$ git commit --fixup <COMMIT HASH OF THE COMMIT "add user component's index view">

# a typo is noticed in the index view

$ git commit --fixup <COMMIT HASH OF THE COMMIT "add user component's index view">

# fix a bug in the view rendering

$ git commit -m "fix view rendering"

$ rubocop
$ yarn lint

# fix linting errors, assuming the linting error was introduced in the commit
# "add user component's edit view"

$ git commit --fixup <COMMIT HASH OF THE COMMIT "add user component's edit view">

# team members do a code review on the PR / MR

$ git commit --fixup <COMMIT HASH OF THE COMMIT "add user component's index view">

The resulting Git log looks like this:

fixup! add user component's index view
fixup! add user component's edit view
fix view rendering
fixup! add user component's index view
fixup! add user component's index view
add user component's edit view
add user component's index view

Instead of regularly committing (and also writing a commit message) we use the --fixup flag to create fixup commits.

Now, before merging the merge request, we issue an interactive rebase with the --autosquash flag.

Note:
GitLab marks MRs that include fixup commits as WIP, so merging is prevented if you haven't squashed.

$ git rebase --interactive --autosquash \
  <COMMIT HASH OF THE COMMIT "add user component's index view">~1

We'll enter interactive rebase mode with the relevant commits already marked for fixup:

pick 364003b add user component's index view
fixup afa6970 fixup! add user component's index view
fixup 1da5d7c fixup! add user component's index view
fixup c998b08 fixup! add user component's index view
pick d9731b5 add user component's edit view
fixup 33d6080 fixup! add user component's edit view
pick 73e8a6a fix view rendering

The resulting Git history looks like this:

fix view rendering
add user component's edit view
add user component's index view

The final result is a very consistent and readable Git history, where every other developer knows what happens, without the uninteresting sidesteps you took while developing.

Summary

In summary, the following two essential Git commands are necessary to make use of the Git fixup workflow:

$ git commit --fixup <COMMIT THAT NEEDS FIXING>
$ git rebase -i --autosquash <FIRST COMMIT THAT NEEDS FIXING>~1

Bonus: Create Git aliases

If you start adopting this workflow, you'll have to type a lot in your terminal. At this point it makes sense to create some Git aliases to ease your brain and hands.

[alias]
    cif = commit --fixup
    ri = rebase -i --autosquash

More bonus: Global autosquash config

Instead of having to provide the --autosquash flag the configuration can be applied globally. The rebase command still requires -i though.

$ git config --global rebase.autoSquash true

Edit (2018-09-18)

I wrote two git scripts git fixup and git squash to support this workflow and added a blog post describing them.