Forem: Richard Taylor

Replacing Webpack with Snowpack in a Phoenix Application

Richard Taylor — Wed, 17 Mar 2021 15:58:15 +0000

Snowpack 3 was recently released and now comes with esbuild support built-in which should mean much faster builds with fewer dependencies, so I replaced Webpack in a fresh phoenix app to see the difference.

tldr; It is incredibly fast and lightweight. See this commit for all the changes required to get this working.

I created a new Phoenix application with LiveView to test this out. LiveView so all the asset config is already set up and we can switch out Webpack for Snowpack.

Firstly I removed all node_modules, webpack.config.js, yarn.lock, .babelrc and all dependencies in package.json except phoenix_html and nprogress which we'll keep.

Then I ran yarn add --dev snowpack to add Snowpack, the final package.json looks like this.

// /assets/package.json

{
  "repository": {},
  "description": " ",
  "license": "MIT",
  "scripts": {
    "deploy": "snowpack build",
    "watch": "snowpack build --no-bundle --watch"
  },
  "dependencies": {
    "phoenix_html": "file:../deps/phoenix_html"
  },
  "devDependencies": {
    "nprogress": "^0.2.0",
    "snowpack": "^3.0.11"
  }
}

I also added the equivalent deploy and watch commands to replace the Webpack ones.

Next was to create a config file for Snowpack that matches the default asset file structure for Phoenix, and configures esbuild to optimize the assets for production.

// /assets/snowpack.config.js

module.exports = {
  mount: {
    "js": { url: "/js" },
    "css": { url: "/css" },
    "static": { url: "/", static: true, resolve: false }
  },
  buildOptions: {
    out: "../priv/static/"
  },
  optimize: {
    entrypoints: ["./static/index.html"],
    bundle: true,
    minify: true,
    target: 'es2018'
  },
};

Only odd thing here is the fake HTML entrypoint I had to set up which references the app.js and app.css. I found without this the optimizer didn't run for app.css, maybe there is a better way of doing this.

Snowpack creates a _snowpack folder in the output directory so we need to add this to the Static Plug in /lib/snowball_web/endpoint.ex.

Snowpack creates ES modules for your JS assets so we need to update the script tag for app.js from type="text/javascipt" to type="module".

Then we need to update the asset watcher that Phoenix starts up to run Snowpack, which now looks like this.

# /config/dev.exs

watchers: [
  node: [
    "node_modules/snowpack/index.bin.js",
    "build",
    "--watch",
    cd: Path.expand("../assets", __DIR__)
  ]
]

The final hurdle was getting the phoenix and phoenix_live_view assets to load. Snowpack didn't like the default import that Phoenix generates so I ended up linking to the Snowpack skypack CDN to get ES module versions of those dependencies and that works great.

The result is incredibly fast start and rebuild times for assets in development and in production.

# development

$ snowpack build --no-bundle
[snowpack] ! building source files...
[snowpack] ✔ build complete [0.01s]
[snowpack] ! building dependencies...
[snowpack] ✔ dependencies ready! [0.09s]
[snowpack] ! verifying build...
[snowpack] ✔ verification complete [0.00s]
[snowpack] ! writing build to disk...
[snowpack] ! optimizing build...
[snowpack] ✔ optimize complete [0.09s]
[snowpack] ▶ Build Complete!

✨  Done in 0.68s.

# production (on Heroku)

$ snowpack build
[snowpack] ! building source files...
[snowpack] ✔ build complete [0.03s]
[snowpack] ! building dependencies...
[snowpack] ✔ dependencies ready! [0.29s]
[snowpack] ! verifying build...
[snowpack] ✔ verification complete [0.00s]
[snowpack] ! writing build to disk...
[snowpack] ! optimizing build...
[snowpack] ✔ optimize complete [0.05s]
[snowpack] ▶ Build Complete!

Done in 0.84s.

That is a vast improvement over the equivalent Webpack setup and results in 17MB of node_modules vs 225MB before the change.

There are caveats to using the built-in esbuild as it says it isn't quite ready for production use yet, but you can add other tried-and-tested plugins to Snowpack if you prefer.

Overall the future is looking good, and I'll be using this from now on.

If you have any comments please add them to this thread on Twitter.

Build a Hybrid SwiftUI app for iOS with Phoenix LiveView

Richard Taylor — Thu, 31 Oct 2019 20:25:45 +0000

I've succesfully published hybrid mobile apps with Turbolinks iOS in the past but Phoenix LiveViews are better suited due to the websocket event handling there is little (or no) HTTP navigation happening.

To demonstrate this we're going to build an iOS app for Flappy Phoenix a LiveView game I created previously.

Create a new iOS project using Single View App in Xcode

Make sure you've selected the SwiftUI user interface

Using SwiftUI we need very little code to get the WebView onto the screen. Update the generated ContentView with

// ContentView.swift

import SwiftUI
import WebKit

struct ContentView: View {
  var body: some View {
    WebView().edgesIgnoringSafeArea(.all)
  }
}

struct WebView: UIViewRepresentable {
  func makeUIView(context: Context) -> WKWebView {
    let webView = WKWebView()
    webView.scrollView.isScrollEnabled = false
    return webView
  }

  func updateUIView(_ webView: WKWebView, context: Context) {
    let liveView = "https://plappy-phoenix.herokuapp.com/game"
    if let url = URL(string: liveView) {
       let request = URLRequest(url: url)
       webView.load(request)
    }
  }
}

#if DEBUG
struct ContentView_Previews : PreviewProvider {
  static var previews: some View {
    ContentView()
  }
}
#endif

This results in a playable iOS app that wraps the LiveView!

It is now possible to extend the interface with SwiftUI components to make it feel more native, while keeping the main body of the app served via the LiveView.

struct ContentView: View {
  var body: some View{
    NavigationView {
      VStack{
        WebView()
      }
      .navigationBarTitle(Text("Flappy Phoenix"))
      .edgesIgnoringSafeArea(.all)
    }
  }
}

This is a simplified example, but hopefully it sparks your imagination of what is possible with LiveView hybrid apps.

In this case I haven't had to make any modifications to the web application but often you might want to make some changes on the server-side eg. hiding the web navigation if you're replacing it with native navigation.

To achieve this we can set a custom user agent in the WebView and then respond to that in the web application:

webView.customUserAgent = "FlappyPhoenix iOS"

If you have any tips or feedback please get in touch via Twitter.

Resources

If you have any tips or feedback please get in touch via Twitter.

Building a BBC Sounds status bar app for macOS

Richard Taylor — Thu, 31 Oct 2019 15:04:09 +0000

Background

I listen to the radio a lot while developing and after trying the available
apps at the time I wrote a simple native status bar app a few years ago in Ruby using the
RubyMotion compiler toolkit.

This allows you to simply switch between a preset list of radio streams
and has media key support so you can pause/play and change station with the
forward/back keys.

This is probably my most used app on the mac but it lacks a lot of features
I really want and I have intended to revisit it for a while.

Having a few rare hours to spare over Christmas this year I started to have a
look at what was available and determined that a WebView app of the
relatively new BBC Sounds web app would be ideal,
the main criteria being:

Native status bar app
WebKit webview of the BBC Sounds site
Media key support for pause/play from the keyboard

Existing tools

There are a couple of projects I'd heard of that assisted you writing apps that
wrap websites in web views so I thought I'd start there.

The webview golang project assists you in writing a
native app with cross-platform support (windows, mac, linux) very simply, this is
literally all you need:

package main

import "github.com/zserge/webview"

func main() {
    webview.Open("BBC Sounds",
        "https://www.bbc.co.uk/sounds/play/live:bbc_6music", 400, 600, true)
}

It really couldn't be any simpler to get started and results in a native player,
job done!

The only downside to this great project is that it abstracts so much away from you
there isn't really any room for customisation, unless you want to get your hands
dirty with C so it doesn't really meet all my criteria.

The WebShell project looked
like it would allow for more customisation at the expense of the cross-platform
support (which isn't essential for me).

Following the instructions and doing a little bit of configuration I had a
player up and running with almost the same results as the webview app. WebShell
also allows you to configure it as a status bar app and has references to the media
keys in the code so I thought I'd hit the jackpot.

Unfortunately there were a number of major bugs, eg. 2 audio streams playing at
the same time and the media keys not doing anything for me that meant it wasn't
going to work.

I figured it would be a good starting point though but after
delving deeper into the code I realised it was doing so much more that I would need
(or understand) that I wouldn't be happy maintaining my fork, if I could even
get it working as I wanted.

At this point though I was starting to understand what was needed to make it work,
and had a great reference app to look at I decided to have a go building it from scratch.

Building the solution

I cracked open a new macOS app in Xcode and found this great tutorial Menus and Popovers in Menu Bar Apps for macOS
that walks you through building a simple status bar app with a popover. This WeatherBar tutorial was also really useful as a second reference. I'm not going to duplicate the setup steps of these tutorials here.

The main gist of the code that gets this working (in the AppDelegate) is:

let statusItem = NSStatusBar.system.statusItem(withLength: NSStatusItem.variableLength)
let popover = NSPopover()

func applicationDidFinishLaunching(_ aNotification: Notification) {
  let icon = NSImage(named: "status")
  icon?.isTemplate = true
  if let button = statusItem.button {
      button.image = icon
      button.action = #selector(togglePopover(_:))
  }
}

@objc func togglePopover(_ sender: Any?) {
    if popover.isShown {
        closePopover(sender: sender)
    } else {
        showPopover(sender: sender)
    }
}

func showPopover(sender: Any?) {
    if let button = statusItem.button {
        popover.show(relativeTo: button.bounds, of: button, preferredEdge: NSRectEdge.minY)
    }
}

func closePopover(sender: Any?) {
    popover.performClose(sender)
}

Once the popup was showing I needed to get a WebView in there and this incredible
article The Ultimate Guide to WKWebView was my frequent reference.

The main detail of the implementation here (in WebViewController) is:

var webView: WKWebView!

override func loadView() {
    let webConfiguration = WKWebViewConfiguration()
    webView = WKWebView(frame: .zero, configuration: webConfiguration)
    view = webView
}

override func viewDidLoad() {
    super.viewDidLoad()
    loadURL(URL(string:"https://www.bbc.co.uk/sounds/play/live:bbc_6music")!)
}

public func loadURL(_ url: URL) {
    webView.load(URLRequest(url: url))
}

At this point the content failed to load, and I discovered I needed to add a
permission to the app to be a network client, apparently this is a relatively
new sandbox security feature in macOS.

With the content loading we have a functional status bar player! One drawback
was that that the audio failed to play automatically until the popover was
opened. I couldn't find a perfect solution to this but hacked in a quick
open/close on launch that worked around it in AppDelegate.

DispatchQueue.main.async {
    self.showPopover(sender: self)
    self.closePopover(sender: self)
}

If you know of a better way of handling this please let me know!

The next part of the puzzle is getting the media keys controlling the player
within the WebView.

I've used the SPMediaKeyTap project
before in the previous player and it worked great. After looking for alternative
solutions that didn't seem to work I found the successor project MediaKeyTap for swift and it worked a treat.

The main gist of the code in AppDelegate

var webController: WebViewController?
var mediaKeyTap: MediaKeyTap?

func applicationDidFinishLaunching(_ aNotification: Notification) {
  ...
  mediaKeyTap = MediaKeyTap(delegate: self)
  mediaKeyTap?.start()
}

func handle(mediaKey: MediaKey, event: KeyEvent) {
    switch mediaKey {
    case .playPause:
        webController?.togglePlay()
    case .previous, .rewind:
        webController?.start()
    case .next, .fastForward:
        webController?.live()
    }
}

This basically just forwards the media key press events to the webview controller.

One gotcha here is that macOS requires you have the accessibilty permission
for the app to receive the events. Under Security & Privacy in macOS settings you need to add the app.

The app will prompt you to do this on first launch, but you need to restart the
app after adding the permission, I couldn't find a way of responding to any
changes in this setting within the running app. If you know a way please let me know.

The last step is to respond to the key events by executing javascript in the
web view.

var webView: WKWebView!

public func togglePlay() {
    execJS("document.getElementById(\"smphtml5iframesmp-wrapper\").contentWindow.document.getElementById(\"p_audioui_playpause\").click()")
}

public func live() {
    execJS("document.getElementById(\"smphtml5iframesmp-wrapper\").contentWindow.document.getElementById(\"p_audioui_toLiveButton\").click()")
}

public func start() {
    execJS("document.getElementById(\"smphtml5iframesmp-wrapper\").contentWindow.document.getElementById(\"p_audioui_backToStartButton\").click()")
}

private func execJS(_ js: String) {
    webView.evaluateJavaScript(js) { (result, error) in
        if let error = error {
            print(error)
        }
    }
}

And that's it! We have a BBC Sounds app with native media key controls and now
I can get back to work :) I really like having the playlist available in the
app too, you can just scroll down to see what is playing and explore further.

The final code is available on GitHub.

If you have any feedback please add it to this thread on Twitter.

An Elixir/Phoenix release workflow for GitHub CI

Richard Taylor — Sun, 27 Oct 2019 10:34:37 +0000

GitHub has made actions available to anyone that requests it and is planning on launching in November so now is a good time to start moving your projects across.

There are a lot more features available now including matrix builds and attached services. GitHub also detects an Elixir repository and gives you a starting point for your workflow.

The default workflow looks like this:

name: Elixir CI

on: push

jobs:
  build:

    runs-on: ubuntu-latest

    container:
      image: elixir:1.9.1-slim

    steps:
    - uses: actions/checkout@v1
    - name: Install Dependencies
      run: |
        mix local.rebar --force
        mix local.hex --force
        mix deps.get
    - name: Run Tests
      run: mix test

This works great for very basic setups, unfortunately for me the first stumbling block was the container image doesn't have any build tools (eg. make) so it wasn't able to compile bcrypt_elixir among other dependencies.

Hovever, the host does have build tools available so instead of running it in a container we can install elixir and erlang (OTP) on the host. GitHub even have an action to do this which is handy!

This makes the basic configuration look like this:

name: Elixir CI

on: push

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v1
    - uses: actions/setup-elixir@v1.0.0
        with:
          otp-version: 22.x
          elixir-version: 1.9.x
    - name: Install Dependencies
      run: |
        mix local.rebar --force
        mix local.hex --force
        mix deps.get
    - name: Run Tests
      run: mix test

This will work as a simple CI for a lot of Elixir projects, but for Phoenix projects we need a bit more.

This configuration sets up a standard Elixir/Phoenix environment (OTP, Elixir and Node) with a Postgres container. It then compiles the code and assets, runs the tests and builds & publishes a release to GitHub releases.

name: Elixir CI

on: push

jobs:
  test:
    runs-on: ${{ matrix.os }}
    name: OTP ${{ matrix.otp }} | Elixir ${{ matrix.elixir }} | Node ${{ matrix.node }} | OS ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-18.04]
        otp: [22.x]
        elixir: [1.9.x]
        node: [12.x]

    services:
      db:
        image: postgres:11
        ports: ['5432:5432']
        options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5

    steps:
      - uses: actions/checkout@v1.0.0
      - uses: actions/setup-elixir@v1.0.0
        with:
          otp-version: ${{ matrix.otp }}
          elixir-version: ${{ matrix.elixir }}
      - uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node }}

      - name: Install dependencies
        run: |
          mix local.rebar --force
          mix local.hex --force
          mix deps.get
          yarn --cwd assets install

      - name: Run tests
        run: |
          mix compile --warnings-as-errors
          mix format --check-formatted
          mix test
        env:
          MIX_ENV: test

      - name: Prepare release
        run: |
          mix compile
          yarn --cwd assets deploy
          mix phx.digest
          mix release
        env:
          MIX_ENV: prod

      - name: Publish release
        uses: moomerman/actions/bin/ghr@master
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          RELEASE_PATH: _build/prod/rel
          APPLICATION: <<APP NAME>>

We've also added the strategy/matrix configuration above which isn't entirely necessary in this example but I like how it ends up having all the versions of dependencies clearly labelled in one place and it allows for extending the matrix to other versions very easily.

A couple of gotchas I found so far (which could be user error) are:

I couldn't find a way of specifying the version of an image in the matrix, eg. v11 of postgres above
I tried to use the ofiicial nodejs docker image to execute the yarn commands rather than running the setup-node action on the host, but this resulted in assets that had permissions that meant the host couldn't modify them which seems like a bug.

The newer format is definitely a lot easier to follow and is extremely powerful. It still takes a while to run, there's no official caching support (though there are a number of optimisations behind the scene) but I expect that to improve soon.

You can see an example of an phoenix project running an adaptation of this configuration on GitHub at moomerman/httping.

If you have any tips or feedback please get in touch via Twitter.