mix bb_nsk.add_web (bb_nsk v0.1.2)

Copy Markdown View Source

Adds the drive pad, the wifi setup page and the Phoenix they need

Gets Phoenix into a Nerves project that has none, mounts the bb_liveview dashboard, and writes two pages of its own: a thumb pad for driving the robot from a phone, and a page for telling it about a network.

Those two are generated into your project rather than mounted from this library. A library carrying Phoenix, tailwind and esbuild assets is awkward to depend on and worse to customise, and the drive pad is the part of this an attendee most obviously wants to change. Only BB.NSK.Drive and its message stay here, because what the pad publishes and what the balance controller consumes has to be the same on both sides.

Where Phoenix comes from

bb_nsk.install adds phx_install as a dependency, and this composes the five of its subtasks a LiveView dashboard needs. Splitting it that way is not tidiness: a package added during an Igniter run is not on the code path for that same run to compose, so it has to be in place a task ahead of the one that uses it.

Phoenix on a Nerves target is not Phoenix on a server

Once Phoenix is there, this mounts the bb_liveview dashboard and fixes the half-dozen places where a board differs from a server:

  • assets.deploy is prepended to the firmware alias. A Nerves release is assembled by mix firmware, which has no idea Phoenix is here, so nothing else builds priv/static and the robot serves a page whose stylesheet 404s. esbuild and tailwind are left exactly as phx.install declares them — runtime: Mix.env() == :dev, which is also what bb_liveview uses — because they have to run during a target build and anything narrower puts them out of reach of it.
  • lazy_html is added for Phoenix.LiveViewTest, which needs a DOM parser and doesn't bring one.
  • sourceror is added because .formatter.exs runs Spark.Formatter through import_deps: [:bb] and nothing else declares it.
  • the live-reload patterns in config/dev.exs get the E modifier, without which mix firmware fails at the release step.
  • config/runtime.exs gets an endpoint block under config_target() != :host binding [::]:80 with server: true. There is no mix phx.server on a device, and mix nerves.new generates no runtime.exs at all, so this creates it.

The endpoint is added to the supervision tree after the robot and the network, because children terminate in reverse start order and a robot nobody can reach is a robot nobody can fix.

Example

mix bb_nsk.add_wifi   # so there is a network to reach it on
mix bb_nsk.add_web

Options

  • --robot - The robot module (defaults to {AppPrefix}.Robot).
  • --auto-phoenix - Install Phoenix without asking. mix bb_nsk.cheat passes this; run the task by hand and it will ask first.
  • --path - Where to mount the bb_liveview dashboard (default /).