-
-
Save fvsch/cfa4455cb6d9f70c3acafeae2c8bf948 to your computer and use it in GitHub Desktop.
Archive of https://fvsch.com/feed.xml on 2021-02-08T12:00
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| <?xml version="1.0" encoding="utf-8"?> | |
| <feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en"> | |
| <title>Florens Verschelde</title> | |
| <id>urn:uuid:c6e9028c-f392-5f5f-9a97-3267a03f1956</id> | |
| <link href="https://fvsch.com/feed.xml" rel="self" type="application/atom+xml"/> | |
| <link href="https://fvsch.com" rel="alternate" type="text/html"/> | |
| <updated>2021-01-11T20:25:38+01:00</updated> | |
| <icon>https://fvsch.com/assets/images/icon.png?v=ql0r5y</icon> | |
| <author> | |
| <name>Florens Verschelde</name> | |
| </author> | |
| <entry xml:lang="en"> | |
| <id>urn:uuid:4baef108-e14e-59e6-935a-52224a141d9e</id> | |
| <link rel="alternate" type="text/html" href="https://fvsch.com/raw-power-mac"/> | |
| <title>RAW Power 3: an affordable digital photo development app for macOS</title> | |
| <published>2021-01-11T00:00:00+01:00</published> | |
| <updated>2021-01-11T00:00:00+01:00</updated> | |
| <summary>My personal review of RAW Power, a photo editing app for macOS and iOS that is shaping up to be an alternative to Lightroom or Aperture.</summary> | |
| <content type="html"><p>I used to dabble in digital photography, even attended a series of workshops for a year. I’m still amateur level, I think, and haven’t shot much in the past 7 years or so. Still, I have a few thousand pictures, some edited and some not at all, that sit in my archives, and I’d like to edit and publish at least some of those.</p> | |
| <p>Only problem: I didn’t have any photo management and development software I’m comfortable with.</p> | |
| <p>I used to own Lightroom 3 and 4. I still do, but they probably don’t install on current Macs, and Adobe made it hard if not impossible to get a license for the current Lightroom Classic app without paying 20 euros per month. So I’ve been looking for alternatives.</p> | |
| <article-nav></article-nav> | |
| <h2><span>Rounding up photo editors</span></h2> | |
| <p>Here’s a list of what I found:</p> | |
| <ul> | |
| <li>Capture One, the priciest option for pros (around €500).</li> | |
| <li>DxO PhotoLab, more affordable (€130); I’ve heard some good things.</li> | |
| <li>ON1 Photo Raw (€102), not a good option for my M1 Mac<sup id="fnref1:1"><a href="#fn:1" class="footnote-ref">1</a></sup>.</li> | |
| <li>Exposure X6 (€110), which seems interesting.</li> | |
| <li>Skylum Luminar (€90 standalone, €150 with their new “AI” tools), which was slow when I tried it a few years back but might have improved since.</li> | |
| <li>Darkroom (€88, or a €22/year subscription), seems to integrate with the Apple Photos library and provide a bunch of tools in a nicely designed package <sup id="fnref1:2"><a href="#fn:2" class="footnote-ref">2</a></sup>.</li> | |
| <li>Photoscape X (€44), seems marketed for the Instagram crowd but could be powerful anyway.</li> | |
| <li>Picktorial ($5/month subscription).</li> | |
| <li>Apple’s own Photos app (included with macOS), which I tried briefly, but I don’t want to import my photos from my archive folders on external drives and into their Photos Library; I hear the development tools are a bit limited too.</li> | |
| </ul> | |
| <p>I also got Affinity Photo and Pixelmator Pro, each for around €50. While they can do some RAW development, and have some great features, they’re closer to Photoshop in spirit. So not my cup of tea. They also don’t include a library browser or manager.</p> | |
| <p>There are a few open-source options too, such as Darktable, RawTherapee and LightZone. I didn’t consider them because they tend to have limited macOS support<sup id="fnref1:3"><a href="#fn:3" class="footnote-ref">3</a></sup>, a steep learning curve, and questionable usability<sup id="fnref1:4"><a href="#fn:4" class="footnote-ref">4</a></sup>.</p> | |
| <p>Finally, after reading <a href="http://austinmann.com/trek/iphone-proraw">this review of the Apple ProRAW format</a>, I discovered a small macOS and iOS app called <a href="https://gentlemencoders.com/raw-power-for-macos/">RAW Power</a>. It piqued my interest since it’s cheap (around €30), runs natively on Apple’s new CPUs, and looks similar in spirit to early versions of Lightroom and Aperture.</p> | |
| <h2><span>The RAW Power UI</span></h2> | |
| <p>RAW Power is developed by Nik Bhatt, who worked for years at Apple on the Aperture team. A bunch of user comments call RAW Power a spiritual successor to Aperture, though at this time its feature set seems more limited (with a few exceptions where it’s more up-to-date).</p> | |
| <p>It was originally a development extension for Apple Photos, before gaining a photo library module in version 2 (improved further in version 3), making it usable as a standalone app as well. You can get a trial version on the app’s website, which is fully functional and adds a watermark to exported photos.</p> | |
| <p>Before trying it out, I took an hour to watch <a href="https://www.youtube.com/watch?v=ME229JqbM48&amp;list=PLgF1Bfd-tVLa8sizMIG2g42x6CdPUmHsb">this video tutorial series recorded by Nik</a>. I especially liked this one, <a href="https://www.youtube.com/watch?v=ONNR8CDgQEc">RAW Power 3 for Mac: Rating and Filtering Workflow</a>. That workflow is not super specific to RAW Power, and could be reproduced in several apps, but sharing this method was a nice touch.</p> | |
| <p>The RAW Power UI looks like this:</p> | |
| <figure class="full"><img src="https://fvsch.com/articles/raw-power-mac/rawpower-ui.png" width="650" height="408" alt="Screenshot of the RAW Power app."></figure> | |
| <p>The UI can be customized a bit, and includes:</p> | |
| <ul> | |
| <li>Top: a toolbar that can be customized and rearranged</li> | |
| <li>Left: a library explorer showing folders or Apple Photos albums</li> | |
| <li>Center: the main photo view</li> | |
| <li>Bottom a tab strip</li> | |
| <li>Right: a sidebar which shows either photo metadata or RAW development tools</li> | |
| </ul> | |
| <p>All those UI components can be hidden or toggled. And if you hide the main photo viewer, the thumbnail strip becomes a bigger thumbnail grid.</p> | |
| <p>This lets you customize your workspace however you want, but sometimes I find that I want to go from one UI configuration to another, and clicking 3 buttons to change things one way and then 3 buttons to change it back is a bit painful.<sup id="fnref1:5"><a href="#fn:5" class="footnote-ref">5</a></sup></p> | |
| <p>On the customizing front, you can also reorder and show or hide each of the RAW “adjustments” modules that appear in the Edit sidebar. The interface for that would benefit from some improvements though, since you need to use different menus to add a module, hide a module, and reorder modules; it would be possible to unify all that in a single, more intuitive config view.</p> | |
| <figure><img src="https://fvsch.com/articles/raw-power-mac/rawpower-adjustment-order.png" width="505" height="390" alt="The Reorder Adjustments dialogue"></figure> | |
| <p>Personally, I’m missing a way to quickly show the photo’s metadata when I’m in Edit mode<sup id="fnref1:6"><a href="#fn:6" class="footnote-ref">6</a></sup>. I have to switch the sidebar from Edit to Info, which takes a good second for some reason, on top of making me lose my place. I’d also love to keep a histogram in Info mode.</p> | |
| <h2><span>The adjustment tools</span></h2> | |
| <p>The adjustment sidebar has a bunch of good tools:</p> | |
| <ul> | |
| <li>A good histogram with black/white and color clipping highlighting.</li> | |
| <li>White Balance (with a decent Auto option and manual control).</li> | |
| <li>A good Crop tool (I like being able to control the precise pixel size and coordinates, it came in handy working on a photo series where I’m trying to align 20 pictures taken from the same spot!), and a Perspective tool that is maybe less intuitive.</li> | |
| <li>Basics/Tone/Enhance has the usual suspects: exposure, brightness, highlights and shadows, clarity…</li> | |
| <li>Black &amp; White, Channel Mixer, HSL Color.</li> | |
| <li>Curves, Levels, Vignette.</li> | |
| <li>A LUT tool that lets you apply predefined styles, including some film simulation or black and white ones. I wasn’t familiar with the “LUT” term, but apparently LUTs are a kind of color map that pairs each input color to its destination color, and there are a bunch of LUTs available online from different providers, with both free and paid options.</li> | |
| </ul> | |
| <figure><img src="https://fvsch.com/articles/raw-power-mac/rawpower-basics.png" width="300" height="390" alt="The Basics, Tone and Enhance controls"><figcaption>Not sure why Brightness is a “Basics” control but “Exposure” is a “Tone” control. Or why Deepen and Lighten are in “Enhance” and not “Tone”, or why “Sharpen” is in a different category (with a single slider) and not in “Enhance”. So I’ve reordered those modules to put them together.</figcaption></figure> | |
| <p>Things I like about the adjustment sliders in RAW Power:</p> | |
| <ul> | |
| <li>It’s easy to see which slider you tweaked (used the system highlight color, which is pink in my case) and which uses the default value.</li> | |
| <li>Double-click resets to the default value.</li> | |
| <li>The numbers are text inputs, and can be edited manually for precision.</li> | |
| </ul> | |
| <p>Some things I don’t like:</p> | |
| <ul> | |
| <li>Sometimes text inputs require two clicks to get focus. Not sure if it’s a bug-bug, or a usability bug somewhere.</li> | |
| <li>Some text inputs support the Up and Down keys to increment or decrement the value, and others don’t, depending on the module.</li> | |
| <li>Based on system settings, it decided I want a comma as the decimal separator, and wouldn’t accept input like <code>1.5</code> (resetting to the default value instead). I worked around it by changing my system settings, but being more forgiving and handing both dots and commas as decimal separators would be better.</li> | |
| <li>The way out of bounds values are handled (if I input <code>5</code> and the maximum is <code>2.0</code>, please use <code>2.0</code> instead of discarding my input).</li> | |
| <li>Slider values are single digit numbers plus two decimals, e.g. <code>1.00</code> or <code>-2.54</code>. Most of them go from <code>0.00</code> to <code>1.00</code>, and would be easier to work with if they were shown as integers between <code>0</code> and <code>100</code> (same precision, but you don’t have to type a decimal separator all the time).</li> | |
| </ul> | |
| <p>Arguably, I’m finicky. That’s the problem when you use and review software as a UI developer &amp; designer. 😛</p> | |
| <p>Overall I like the tools, they’re rather powerful. There are a few useful presets you can apply, and a couple “Auto Enhance” features which look decent but not quite magical.</p> | |
| <p>One tool which is both powerful and a bit confusing is the RAW Processing adjustment. It shows 9 sliders and a couple options:</p> | |
| <figure><img src="https://fvsch.com/articles/raw-power-mac/rawpower-raw-processing.png" width="300" height="315" alt="The RAW Processing controls, with sliders such as Boost, Black Point, Luma Nose, Color Noise, Moiré, and RAW Sharpen"></figure> | |
| <p>The noise controls are part of this first RAW processing pass. I haven’t worked with very noisy images yet, so I’m not sure if they’re good. The Color Noise correction seems to work well.</p> | |
| <p>The “Boost” feature is interesting. It’s set at its maximum by default. If you move it back to 0%, you get a much more washed-out, lifeless picture, like you get in some RAW processing software out of the box (especially in some of the open-source ones, when they’re not set up to apply some default enhancements). Comparing the results at 0%, 50% and 100% Boost, I tend to like what it does.</p> | |
| <figure class="full"><img src="https://fvsch.com/articles/raw-power-mac/boost-demo.jpg" width="680" height="450" alt="A side-by-side comparison of the same image with two different development settings. Left one looks a bit gray and lacks contrast. Right one is more colorful and contrasted."><figcaption>Boost at 0% and 100%</figcaption></figure> | |
| <p>In the video tutorials, Nik shows how sometimes Boost goes a bit too far, and it’s better to lower it a bit or completely before applying other adjustments (such as highlight recovery). I’ve sometimes moved it down to 90% or 80%, but rarely all the way down.</p> | |
| <p>Another slider I’ve used at times is Black Point, which er makes more or fewer parts of the image black or dark?</p> | |
| <p>Sometimes it looks like there are a few ways to do the same thing, especially when it comes to contrast with: Boost, RAW Contrast, Contrast, Curves and Levels, to name a few. Or micro-contrast with RAW Sharpen, Clarity and Sharpen. It probably takes some time and expertise to learn what works best for you and your images.</p> | |
| <p>I just discovered the <a href="https://gentlemencoders.com/wp-content/uploads/2020/04/RAW-Power-3.0-for-Mac-Help.pdf">RAW Power user manual (50 page PDF)</a>, which has more details on how adjustments work. Maybe that’ll clarify what the best approach is for some use cases.</p> | |
| <figure><img src="https://fvsch.com/articles/raw-power-mac/rawpower-curves.png" width="300" height="390" alt="The Curves adjustment tool"><figcaption>The Curves tool is powerful and lets you set as many points as you want, but it’s hard to move a point just right on the vertical axis, and a little nudge can have an overblown effect. I was a bit more at ease with Lightroom’s four number inputs, which make it easy to create a symmetrical S-curve and control how strong the effect is.</figcaption></figure> | |
| <p>Finally, there are no local adjustment tool: no brushes, no gradients, no repair, etc. While things like machine-learning based local repairs can be done by other software working on an exported TIFF file, it would be great to at least have support for gradient filters, e.g. to handle sky-vs-land exposure.</p> | |
| <p>RAW Power 3.2 added support for Apple’s ProRAW (part of the DNG 1.6 format), which includes precomputed local adjustments from the iPhone’s software as a kind of mask or extra layer (I’m not sure) that you can turn on or off or apply partially. Maybe some of the work done on ProRAW support lays the groundwork for local adjustments? One can dream. 😄</p> | |
| <h2><span>Data portability</span></h2> | |
| <p>In an ideal world, adjustments made to a RAW photo in one app would be understood by another app. Sadly we don’t leave in this world, because RAW development and image correction algorithms are specific to each app, and there’s no standard even for common things such as exposure correction, black and white or color processing, curves, vignette, embedded LUTs, etc.</p> | |
| <p>So development settings done in Lightroom, RAW Power or DxO PhotoLab won’t be interoperable at all. Okay. But can we at least make sure that those development settings are saved reliably?</p> | |
| <p>Lightroom lets you write development settings as “sidecar files”, which use the <code>.xmp</code> extension, or embedded inside DNG files. This comes in handy when syncing files via Dropbox, saving photos on an external drive, or changing computers or operating system.</p> | |
| <p>RAW Power saves development data in <code>Documents/RAW Power</code>, with no option to use sidecar files. This folder may look like this:</p> | |
| <figure><img src="https://fvsch.com/articles/raw-power-mac/rawpower-metadata.png" width="555" height="370" alt="The RAW Power folder, which stores JPEG previews and development data with a .rawpower extension"></figure> | |
| <p>If you move or rename a photo, you risk losing the link with this development data, as stated in the help pages:</p> | |
| <blockquote> | |
| <p>RAW Power stores its editing and rating / flag information in files stored within its “sandbox,” which is a directory inside your home folder on your disk. RAW Power stores information in the sandbox that lets it connect its data with your original images. Part of the identifier is the file name of your image, and part is the identifier generated by macOS. As a result of this system, RAW Power can connect editing and rating information to your original even if you move the file elsewhere on your disk. However, if you rename it, or move it to another volume, the link is broken.</p> | |
| </blockquote> | |
| <p>So if you store photos on a drive, that drive dies and you later get a backup of your photos: sorry, your development data will be lost or not linked to the photos.</p> | |
| <p>In my book, that’s a serious risk that will have me keep looking at alternatives.</p> | |
| <h2><span>My recommendation</span></h2> | |
| <p>Despite a few pain points and concerns, I find that RAW Power is a capable tool and I’ll probably use it more in the future, while keeping an eye on the pricier competition.</p> | |
| <p>If you liked Lightroom Classic or Aperture, RAW Power might be a good fit for you, provided you can forgive a few issues and missing features.</p> | |
| <p>RAW Power is, as far as I can tell, indie software with a team of one and a low price. It should give you a lot of value for your money.</p> | |
| <p>I heartily recommend giving it a try.</p> | |
| <div class="footnotes"> | |
| <hr /> | |
| <ol> | |
| <li id="fn:1"> | |
| <p>I bought a ON1 Photo Raw 2020 license in a sale last year. It fails to install on my computer. The 2021 version — a somewhat pricy upgrade — is an Intel app that runs too slowly to be comfortable. I might reconsider later if the price and performance are right.&#160;<a href="#fnref1:1" rev="footnote" class="footnote-backref">&#8617;</a></p> | |
| </li> | |
| <li id="fn:2"> | |
| <p>Subjectively and just based on screenshots, Darkroom has the most attractive design.&#160;<a href="#fnref1:2" rev="footnote" class="footnote-backref">&#8617;</a></p> | |
| </li> | |
| <li id="fn:3"> | |
| <p>Darktable tells you “Good Luck :)” if you want to install a macOS version.&#160;<a href="#fnref1:3" rev="footnote" class="footnote-backref">&#8617;</a></p> | |
| </li> | |
| <li id="fn:4"> | |
| <p>That’s not a condemnation of those projects. I understand that open-source side projects made by developers might focus on Linux support and/or powerful features that scratch one’s itch over the years-long design process needed for best-in-class usability.&#160;<a href="#fnref1:4" rev="footnote" class="footnote-backref">&#8617;</a></p> | |
| </li> | |
| <li id="fn:5"> | |
| <p>For browsing and rating I might show the left sidebar, a thumbnail grid with medium thumbnails, and the metadata sidebar. For editing a particular photo, I’d hide the left sidebar, show the main photo view, and either hide the thumbnails or keep them at the smallest size. If I count the clicks needed to go from the first configuration to the other one: that’s 4 clicks.&#160;<a href="#fnref1:5" rev="footnote" class="footnote-backref">&#8617;</a></p> | |
| </li> | |
| <li id="fn:6"> | |
| <p>For instance, I’ve wanted to check data such as the shooting date and hour when tweaking white balance, to make sure the white balance is consistent with the hour and season when I’m going for a realistic look.&#160;<a href="#fnref1:6" rev="footnote" class="footnote-backref">&#8617;</a></p> | |
| </li> | |
| </ol> | |
| </div></content> | |
| </entry> | |
| <entry xml:lang="en"> | |
| <id>urn:uuid:2380b5bb-eb96-5bed-9f3c-8ad36e8deb61</id> | |
| <link rel="alternate" type="text/html" href="https://fvsch.com/learning-xstate"/> | |
| <title>Learning XState by refactoring an old project</title> | |
| <published>2021-01-06T17:00:00+01:00</published> | |
| <updated>2021-01-06T17:00:00+01:00</updated> | |
| <summary>I’ve been wanting to learn XState, a JavaScript state machine library. I had one exercise in mind: porting the hand-rolled state code in the small click precision game I built last year, if possible.</summary> | |
| <content type="html"><p>For a while I’ve wanted to learn the <a href="https://xstate.js.org">XState library</a>, which is presented as a solution to gnarly UI state issues where “what should we show and how should it act?” becomes hard to determine.</p> | |
| <p>Since the best way to learn is to actually build something, I’m thinking I can try to port an old project of mine over to XState, and see how it turns out. Continue reading if you want to follow along!</p> | |
| <article-nav></article-nav> | |
| <h2><span>Why state machines?</span></h2> | |
| <p>I’ve been building a bunch of app or app-like user interfaces with React and other frameworks, and you quickly run into situations where a screen or component’s UI state is represented by a series of variables.</p> | |
| <p>For instance, if a component loads data from a server, you can end up with variables like:</p> | |
| <ul> | |
| <li><code>data</code> (<code>undefined</code>, empty Array, or Array with data)</li> | |
| <li><code>error</code> (<code>undefined</code> or an error object or message)</li> | |
| <li><code>loading</code> (boolean)</li> | |
| </ul> | |
| <p>You end up writing conditions like this:</p> | |
| <pre><code class="language-js">const hasContent = | |
| !error &amp;&amp; | |
| !loading &amp;&amp; | |
| Array.isArray(data) &amp;&amp; | |
| data.length &gt; 0;</code></pre> | |
| <p>Add a couple more UX or business rules to this UI component, and you’re in trouble. Your code will be littered with complex conditions, and it’s easy to get one of those wrong and end up with subtle bugs where different parts of the UI disagree about what state the application or component is in. So, what’s a poor UI developer to do?</p> | |
| <p>Enter finite-state machines.</p> | |
| <p>As a literature major with no formal computer science training, I’m not quite sure what I’m talking about, but apparently a <a href="https://en.wikipedia.org/wiki/Finite-state_machine">“finite-state machine”</a> is a programming concept where:</p> | |
| <ul> | |
| <li>the program has a list of possible states;</li> | |
| <li>it can be in only one state at a time;</li> | |
| <li>and it defines how each state can or cannot transition to other states.</li> | |
| </ul> | |
| <p>This can be used to describe physical devices like elevators, traffic lights, vending machines and more, and often those devices do run programs that implement a finite-state machine.</p> | |
| <p>Last year I built a tiny <a href="https://click-precision-game.netlify.app/">click precision game</a>, with zero experience in game development. I used <a href="https://svelte.dev/">Svelte</a>, and designed the game’s state somewhat naively. Often thinking “I should use an established formalism here” but being pressed for time, I improvised some ad hoc code.</p> | |
| <p>Shortly after that, I heard of XState, a JavaScript library that helps with implementing state machines. And I wondered how would things have worked out if I had used XState. Let’s find out!</p> | |
| <h2><span>How the game currently works</span></h2> | |
| <p>Since this is a refactoring operation, we should review key parts of the <a href="https://github.com/fvsch/click-precision-game/tree/v1.0.0">current code for click-precision-game</a>. How does it handle the main gameplay state?</p> | |
| <p>Let’s look at the main gameplay in the <a href="https://github.com/fvsch/click-precision-game/blob/v1.0.0/src/components/Playground.svelte"><code>Playground.svelte</code> component</a>. There’s a lot of logic there. The game follows a linear timeline where each instance of the game is divided in two parts:</p> | |
| <ol> | |
| <li>A countdown, divided in a few phases (showing “click the green square”, “3”, “2”, “1”).</li> | |
| <li>Then a series of 20 “turns”, each turn divided in 2 phases: the “turn” itself (time when the game’s target is visible and must be clicked), and a “cooldown” (short pause before the next turn).</li> | |
| </ol> | |
| <p>That information is encoded as a collection of objects:</p> | |
| <pre><code class="language-js">export const PLAY_PHASES = { | |
| START: { | |
| next: "COUNTDOWN_3", | |
| durationRatio: 1, | |
| minDuration: 1000, | |
| countdown: 4, | |
| showTarget: false, | |
| }, | |
| COUNTDOWN_3: { | |
| next: "COUNTDOWN_2", | |
| durationRatio: 0.5, | |
| minDuration: 400, | |
| countdown: 3, | |
| showTarget: false, | |
| }, | |
| COUNTDOWN_2: { | |
| next: "COUNTDOWN_1", | |
| /* … */ | |
| }, | |
| COUNTDOWN_1: { | |
| next: "TURN", | |
| /* … */ | |
| }, | |
| TURN: { | |
| next: "COOLDOWN", | |
| /* … */ | |
| }, | |
| COOLDOWN: { | |
| next: "TURN", | |
| /* … */ | |
| } | |
| };</code></pre> | |
| <p>When the <code>Playground</code> component is mounted, we’re triggering the first phase:</p> | |
| <pre><code class="language-js">onMount(() =&gt; { | |
| startPhase("START"); | |
| });</code></pre> | |
| <p>And the <code>startPhase</code> function does the heavy lifting. Here it is, partly abridged and annotated:</p> | |
| <pre><code class="language-js">function startPhase(key) { | |
| // If we’re just starting a turn | |
| if (key === "TURN") { | |
| // increment the turn count | |
| turns += 1; | |
| // reset the success/failure state to a neutral value | |
| turnState = TURN_STATE.INITIAL; | |
| // place the target at a random position | |
| targetPosition = getTargetPosition(); | |
| } | |
| // If ending a turn, we check the component state | |
| // to see if we have registered a successful click | |
| // on the target | |
| if (key === "COOLDOWN") { | |
| if (turnState === TURN_STATE.SUCCESS) { | |
| successCount += 1; | |
| } | |
| } | |
| // Get config for this phase | |
| const phase = PLAY_PHASES[key]; | |
| // update UI | |
| countdown = phase.countdown; | |
| showTarget = phase.showTarget; | |
| // schedule next phase | |
| timeout = setTimeout( | |
| () =&gt; startPhase(phase.next), | |
| Math.max(phase.minDuration, phase.durationRatio * $gameSpeed) | |
| ); | |
| }</code></pre> | |
| <p>Note that the <code>countdown</code> and <code>showTarget</code> variables are reactive, and tracked by Svelte. When we update their value, Svelte does its <a href="https://svelte.dev/blog/svelte-3-rethinking-reactivity">reactivity magic</a> and updates the view. If we were in React land, we could probably use <code>useState</code> and update these state variables with:</p> | |
| <pre><code class="language-js">const [countdown, setCountdown] = useState(); | |
| const [showTarget, setShowTarget] = useState(); | |
| const startPhase = (key) =&gt; { | |
| /* … */ | |
| setCountdown(phase.countdown); | |
| setShowTarget(phase.showTarget); | |
| /* … */ | |
| }</code></pre> | |
| <p>Anyway, that’s how it works right now. Doing a bit of reading on <a href="https://statecharts.github.io/">statecharts</a> and <a href="https://css-tricks.com/robust-react-user-interfaces-with-finite-state-machines/">this introduction to state machines by David Khourshid on CSS-Tricks</a>, it looks like I was close enough to a hand-rolled finite state machine. Yay me!</p> | |
| <h2><span>Getting comfortable with XState</span></h2> | |
| <p>Originally I wanted to open the XState docs in one tab, my current code on another screen, and just start converting stuff and figuring things out along the way.</p> | |
| <p>Turns out that XState is a bit more complex than I thought. It’s not very hard, but there are a few concepts to learn: machines, services, actions, actors maybe? Is that more than I bargained for?</p> | |
| <p>So, change of plan: before tacking the gameplay state, I want to make sure I’m comfortable with basic usage of XState and how to integrate it in Svelte.</p> | |
| <p>Let’s start with a simpler bit of state then; I picked the main navigation state.</p> | |
| <p>The game has 3 different screens:</p> | |
| <ul> | |
| <li><code>"setup"</code> (configures a game’s parameters before starting)</li> | |
| <li><code>"playing"</code> (plays the game’s main loop)</li> | |
| <li><code>"results"</code> (shows your points)</li> | |
| </ul> | |
| <p>We start at the Setup screen:</p> | |
| <figure><img src="https://fvsch.com/articles/learning-xstate/game-setup-screen.png" width="504" height="504" alt="A start screen with form fields for choosing a target size, playground size and game speed, and a “Start” button."></figure> | |
| <p>The information for “which screen should we show?” is stored as a string in a Svelte store (a reactive variable that can be shared between components). It’s defined like this:</p> | |
| <pre><code class="language-js">import { writable } from "svelte/store"; | |
| export const screen = writable("setup");</code></pre> | |
| <p>And in our root component we have a kind of switch statement where we pick which component to render:</p> | |
| <pre><code class="language-svelte">&lt;script&gt; | |
| import { screen } from "../store.js"; | |
| import Setup from "./Setup.svelte"; | |
| /* … */ | |
| &lt;/script&gt; | |
| {#if $screen === "setup"} | |
| &lt;Setup /&gt; | |
| {:else if $screen === "playing"} | |
| &lt;Playground /&gt; | |
| {:else if $screen === "results"} | |
| &lt;Results /&gt; | |
| {/if}</code></pre> | |
| <p>To navigate between screens, we change the store’s value:</p> | |
| <pre><code class="language-js">function startPlaying() { | |
| $screen = "playing"; | |
| }</code></pre> | |
| <p>Note: we’re using the dollar syntax, <code>$screen</code>, to access the value of the <code>screen</code> store in a reactive way (<a href="https://svelte.dev/docs#4_Prefix_stores_with_$_to_access_their_values">read more in the Svelte docs</a>).</p> | |
| <p>Converting this to XState is probably overkill, but using XState we can enforce a few rules:</p> | |
| <ol> | |
| <li>Restrict the state to known values (e.g. make it impossible to set the current screen to <code>"whoops"</code> if that’s not a known state).</li> | |
| <li>Specify relationships between states, e.g. only the <code>"playing"</code> state can go to the <code>"results"</code> state.</li> | |
| </ol> | |
| <p>Let’s create a basic XState machine to keep track of the current screen:</p> | |
| <pre><code class="language-js">// src/state/screen.js | |
| import { Machine } from "xstate"; | |
| const screenMachine = Machine({ | |
| id: "screen", | |
| initial: "setup", | |
| states: { | |
| setup: {}, | |
| playing: {}, | |
| results: {} | |
| } | |
| });</code></pre> | |
| <p>Right now our 3 states have no rules or features attached, but we’ll flesh them out later.</p> | |
| <p>Now if I’m understanding correctly, a XState “machine” is a static set of rules, but it is itself stateless: it doesn’t have a current state or a state history. To hold a “current value”, we need a XState “service”:</p> | |
| <pre><code class="language-js">// src/state/screen.js | |
| import { interpret, Machine } from "xstate"; | |
| const screenMachine = Machine({ | |
| id: "screen", | |
| initial: "setup", | |
| states: { | |
| setup: {}, | |
| playing: {}, | |
| results: {} | |
| } | |
| }); | |
| const screenService = interpret(screenMachine); | |
| export default screenService;</code></pre> | |
| <p>This feels a bit like a class-vs-instance thing. We have a kind of blueprint (a class, or a machine in this case) which is used to create a structure that holds data or state (instance/service). Not sure if that makes sense, this is just how it looks to me. 😅</p> | |
| <p>Let’s update our top component to use the <code>screenService</code> instead of the <code>screen</code> Svelte store:</p> | |
| <pre><code class="language-svelte">&lt;script&gt; | |
| import screenService from "../state/screen.js"; | |
| import Setup from "./Setup.svelte"; | |
| /* … */ | |
| &lt;/script&gt; | |
| {#if screenService.state.matches("setup")} | |
| &lt;Setup /&gt; | |
| {:else if screenService.state.matches("playing")} | |
| &lt;Playground /&gt; | |
| {:else if screenService.state.matches("results")} | |
| &lt;Results /&gt; | |
| {/if}</code></pre> | |
| <p>This looks good to me, but alas! it fails. We get a blank screen. What’s going on in the Console?</p> | |
| <blockquote> | |
| <p>Warning: Attempted to read state from uninitialized service 'screen'. Make sure the service is started first.</p> | |
| </blockquote> | |
| <p>Indeed, when we run <code>console.log(screenService.state)</code>, that’s <code>undefined</code>! Looks like we have to start the service to make it go to its initial state (<code>"setup"</code>):</p> | |
| <pre><code class="language-js">const screenService = interpret(screenMachine); | |
| screenService.start();</code></pre> | |
| <p>That works! I’m seeing the Setup screen, and if I change the <code>initial</code> value in <code>stateMachine</code> and reload the page I can see the Playground or Results components — though Results are broken, because the result data is missing.</p> | |
| <p>So we have a navigation state. Now we need some navigation actions, i.e. a way to go from one state to the other.</p> | |
| <p>XState handles that with events, which are defined on the machine. It looks like, by convention, state names are lowercase and event names are uppercase, so we’ll follow that.</p> | |
| <pre><code class="language-js">const screenMachine = Machine({ | |
| id: "screen", | |
| initial: "setup", | |
| states: { | |
| setup: { | |
| on: { | |
| START_PLAYING: "playing" | |
| } | |
| }, | |
| playing: { | |
| on: { | |
| SHOW_RESULTS: "results", | |
| SHOW_SETUP: "setup" | |
| } | |
| }, | |
| results: { | |
| on: { | |
| SHOW_SETUP: "setup" | |
| } | |
| } | |
| } | |
| });</code></pre> | |
| <p>With that setup:</p> | |
| <ol> | |
| <li>to start playing, we must be on the <code>"setup"</code> state and send a <code>"START_PLAYING"</code> event;</li> | |
| <li>the <code>"playing"</code> state can go to the <code>"results"</code> state or to the <code>"setup"</code> state (e.g. if the user wants to interrupt a game);</li> | |
| <li>the <code>"results"</code> state can only go back to the <code>"setup"</code> state, to start a new game.</li> | |
| </ol> | |
| <p>And we could add events to handle more features. For instance, if we want to add a “Try Again” button on the results screen that starts a new game with the same parameters, we can add: <code>PLAY_AGAIN: "playing"</code>.</p> | |
| <p>We send events with the service’s <code>send</code> method. Let’s start with the <code>Setup</code> page. It listens to the form’s <code>"submit"</code> event and navigates, so we’ll update that:</p> | |
| <pre><code class="language-js">// src/components/Setup.svelte | |
| &lt;script&gt; | |
| import screenService from "../state/screen.js"; | |
| function onSubmit(event) { | |
| event.preventDefault(); | |
| screenService.send("START_PLAYING"); | |
| } | |
| &lt;/script&gt; | |
| &lt;form on:submit={onSubmit}&gt; | |
| &lt;!-- … --&gt; | |
| &lt;/form&gt;</code></pre> | |
| <p>And… it doesn’t work.</p> | |
| <p>Nothing in the Console. Hmm, how else can we debug what’s happening? We have two options:</p> | |
| <ul> | |
| <li>add a bunch of <code>console.log</code>s;</li> | |
| <li>use the Redux DevTools browser extension and <a href="https://xstate.js.org/docs/guides/interpretation.html#options">tell XState to send it state information</a>.</li> | |
| </ul> | |
| <p>Looking closer, once we call <code>send("START_PLAYING")</code>, here is what happens:</p> | |
| <ol> | |
| <li>The event is dispatched correctly on the <code>screenService</code>.</li> | |
| <li>The <code>screenService</code>’s state changes to <code>"playing"</code>.</li> | |
| <li>But nothing in <code>Game.svelte</code> reacts to this change.</li> | |
| </ol> | |
| <p>We need to make Svelte aware of changes in the <code>screenService</code>!</p> | |
| <p>Thankfully, XState’s docs have <a href="https://xstate.js.org/docs/recipes/svelte.html">a recipe for using XState with Svelte</a>, which shows two solutions. My favorite is to treat the XState service as a Svelte store, which is possible because a XState service has a <code>subscribe</code> method that <a href="https://svelte.dev/docs#Store_contract">fulfills Svelte’s “store contract”</a>.</p> | |
| <p>In short, that means we can use <code>$screenService</code> as a reactive version of <code>screenService.state</code>. Our code becomes:</p> | |
| <pre><code class="language-svelte">&lt;script&gt; | |
| import screenService from "../state/screen.js"; | |
| /* … */ | |
| &lt;/script&gt; | |
| {#if $screenService.matches("setup")} | |
| &lt;Setup /&gt; | |
| {:else if $screenService.matches("playing")} | |
| &lt;Playground /&gt; | |
| {:else if $screenService.matches("results")} | |
| &lt;Results /&gt; | |
| {/if}</code></pre> | |
| <p>And with that, navigating between screens finally works!</p> | |
| <h2><span>Tackling the main game loop</span></h2> | |
| <p>Okay, that wasn’t super simple and there was a bit of a learning curve, but we finally know how to make a basic state machine with XState. Should we create one for the <code>PLAY_PHASES</code> structure we described earlier? As a reminder, it looked like this:</p> | |
| <pre><code class="language-js">export const PLAY_PHASES = { | |
| START: { | |
| next: "COUNTDOWN_3" | |
| }, | |
| COUNTDOWN_3: { | |
| next: "COUNTDOWN_2" | |
| }, | |
| COUNTDOWN_2: { | |
| next: "COUNTDOWN_1" | |
| }, | |
| COUNTDOWN_1: { | |
| next: "TURN" | |
| }, | |
| TURN: { | |
| next: "COOLDOWN" | |
| }, | |
| COOLDOWN: { | |
| next: "TURN" | |
| } | |
| };</code></pre> | |
| <p>The first-level keys are our states, and we have just one event, <code>"next"</code>, telling us what the next state should be.</p> | |
| <p>As a XState machine, this could look like:</p> | |
| <pre><code class="language-js">const playMachine = Machine({ | |
| id: "play", | |
| initial: "start", | |
| states: { | |
| start: { | |
| on: { NEXT: "countdown_3" } | |
| }, | |
| countdown_3: { | |
| on: { NEXT: "countdown_2" } | |
| }, | |
| countdown_2: { | |
| on: { NEXT: "countdown_1" } | |
| }, | |
| countdown_1: { | |
| on: { NEXT: "turn" } | |
| }, | |
| turn: { | |
| on: { NEXT: "cooldown" } | |
| }, | |
| cooldown: { | |
| on: { NEXT: "turn" } | |
| } | |
| } | |
| });</code></pre> | |
| <p>While working on the XState refactor for this article, I realized that the 4 first states (from <code>"start"</code> to <code>"countdown_1</code>) represent a single countdown animation with 4 “stages”. To simplify the state logic a bit, I decided to turn those states into a single <code>“countdown”</code> state, and moved the animation logic to <a href="https://github.com/fvsch/click-precision-game/blob/v2.0.0/src/components/Countdown.svelte">a CSS animation in the Countdown component</a>. This simplifies our machine:</p> | |
| <pre><code class="language-js">const playMachine = Machine({ | |
| id: "play", | |
| initial: "countdown", | |
| states: { | |
| countdown: { | |
| on: { NEXT: "turn" } | |
| }, | |
| turn: { | |
| on: { NEXT: "cooldown" } | |
| }, | |
| cooldown: { | |
| on: { NEXT: "turn" } | |
| } | |
| } | |
| });</code></pre> | |
| <p>Another problem to solve: how do we start this <code>playMachine</code> at the right time in our app’s life?</p> | |
| <p>One solution would be to create and start a new <code>playService</code> every time that the <code>Playground</code> component is mounted.</p> | |
| <p>Another option is to merge our <code>screenMachine</code> and our <code>playMachine</code> in one <a href="https://xstate.js.org/docs/guides/hierarchical.html">hierarchical state machine</a>. The states from our <code>playMachine</code> can be children of the <code>playing</code> state.</p> | |
| <p>(You don’t need to have a single machine for your whole app’s state. It’s perfectly okay to have several machines for several features or screens. But since the game loop only exists in the <code>"playing"</code> screen, a single hierarchical machine makes sense here.)</p> | |
| <p>Our merged machine will handle most of the game’s state, so let’s call it <code>gameMachine</code>:</p> | |
| <pre><code class="language-js">// src/state/game.js | |
| import { interpret, Machine } from "xstate"; | |
| const gameMachine = Machine({ | |
| id: "game", | |
| initial: "setup", | |
| states: { | |
| setup: { | |
| on: { | |
| START_PLAYING: "playing", | |
| } | |
| }, | |
| playing: { | |
| on: { | |
| SHOW_RESULTS: "results", | |
| SHOW_SETUP: "setup" | |
| }, | |
| initial: "countdown", | |
| states: { | |
| countdown: { | |
| on: { NEXT: "turn" } | |
| }, | |
| turn: { | |
| on: { NEXT: "cooldown" } | |
| }, | |
| cooldown: { | |
| on: { NEXT: "turn" } | |
| } | |
| } | |
| }, | |
| results: { | |
| on: { | |
| SHOW_SETUP: "setup" | |
| } | |
| } | |
| } | |
| }); | |
| const gameService = interpret(gameMachine); | |
| gameService.start(); | |
| export default gameService;</code></pre> | |
| <p>This machine can be <a href="https://xstate.js.org/viz/?gist=897990dba921cb329062644d3b551c65">visualized using XState’s interactive visualizer</a>:</p> | |
| <figure class="frame"><iframe width="100%" height="400" src="https://xstate.js.org/viz/?gist=897990dba921cb329062644d3b551c65&amp;embed=1" title="OK"></iframe> | |
| </figure> | |
| <p>If you try clicking on the event names in the visualization, you’ll see that:</p> | |
| <ol> | |
| <li>We start at the <code>setup</code> state.</li> | |
| <li>We can go to the <code>playing</code> state, which starts at its <code>playing.countdown</code> state.</li> | |
| <li>In the <code>playing</code> state, we can go to <code>playing.turn</code>, then to <code>playing.cooldown</code>, then to <code>playing.turn</code> again, and we stay there in a loop.</li> | |
| <li>We can go from the <code>playing</code> state forward to the <code>results</code> state, or back to <code>setup</code>.</li> | |
| </ol> | |
| <p>Pretty good. Now, in the <code>Playground</code> component we need to react to changes in the game state to:</p> | |
| <ul> | |
| <li>show or hide the countdown;</li> | |
| <li>show the square target with a new position, and increment the turn count;</li> | |
| <li>hide the square target.</li> | |
| </ul> | |
| <p>Most of that logic happens in the <code>startPhase</code> function we described earlier. Our previous logic relied on calling <code>startPhase</code> recursively, with a delay. Schematically, it looked like:</p> | |
| <pre><code class="language-js">import { onMount } from "svelte"; | |
| import { PLAY_PHASES } from "./constants.js"; | |
| onMount(() =&gt; { | |
| startPhase("countdown"); | |
| }); | |
| function startPhase(key) { | |
| // 1. Perform side effects (update the UI): | |
| // … | |
| // 2. Set a timer for the next phase: | |
| const nextKey = PLAY_PHASES[key].next; | |
| const duration = PLAY_PHASES[key].duration; | |
| setTimeout(() =&gt; { | |
| startPhase(nextKey); | |
| }, duration); | |
| }</code></pre> | |
| <p>With our state machine, we’re going to split this in two:</p> | |
| <ul> | |
| <li>We’re going to call <code>startPhase</code> every time the <code>gameService</code>’s state changes. For that, we need to subscribe to updates.</li> | |
| <li>At the end of a game phase (in our <code>setTimeout</code> function), we’re going to send a <code>"NEXT"</code> event instead of calling <code>startPhase</code> directly.</li> | |
| </ul> | |
| <pre><code class="language-js">import { onMount, onDestroy } from "svelte"; | |
| import gameService from "../state/game.js"; | |
| import { gamePhaseDurations } from "../state/setup.js"; | |
| // Listen to state transitions | |
| onMount(() =&gt; { | |
| gameService.onTransition(startPhase); | |
| }); | |
| onDestroy(() =&gt; { | |
| gameService.off(startPhase); | |
| }); | |
| function startPhase(state) { | |
| // state.value looks like: {playing: "countdown"} | |
| const key = state.value.playing; | |
| // 1. Perform side effects (update the UI): | |
| // … | |
| // 2. Set a timer for the next phase: | |
| const duration = $gamePhaseDurations[key]; | |
| setTimeout(() =&gt; { | |
| gameService.send("NEXT"); | |
| }, duration); | |
| }</code></pre> | |
| <p>And we’re done!</p> | |
| <p>The <a href="https://github.com/fvsch/click-precision-game/blob/v2.0.0/src/components/Playground.svelte">actual logic</a> is a bit more complex — it handles things like counting turns and points, sending a <code>send("SHOW_RESULTS")</code> event after 20 turns, etc. — but this is a good representation of how the state machine powers the game loop.</p> | |
| <h2><span>My impressions of XState</span></h2> | |
| <p>I found XState to be more complex than I had anticipated. Granted I knew next to nothing about state machines and <a href="https://statecharts.github.io">statecharts</a>. But the learning curve was a bit steep, I think, for two reasons:</p> | |
| <ol> | |
| <li>There’s a bit of jargon to wrap your head around.</li> | |
| <li>XState has a lot of features, and it’s easy to get lost asking yourself if one feature is essential for your use case or not, or that other feature, or maybe this one…</li> | |
| </ol> | |
| <p>At first I tried diving in for a couple hours, writing some code, expecting to know my way around the concepts and library in that time-frame. That didn’t work at all.</p> | |
| <p>So I took a step back, actually read some of the docs, watched a couple videos and read some articles, before diving back in with a smaller scope: porting the navigation state.</p> | |
| <p>After that, porting the main game loop to XState was still a lot of work, but mostly because my own UI logic had a lot of parts to account for, and changing some of its state management meant I had a lot of loose ends to reconnect.</p> | |
| <figure><img width="620" height="402" src="https://fvsch.com/articles/learning-xstate/telephone-switchboard-operator.jpg" alt="An operator plugging cables in an very big switchboard"><figcaption>Me trying to make <code>Playground.svelte</code> work again.</figcaption></figure> | |
| <p>While I initially wanted to spend 1–2 days learning XState, I ended up spending close to a week learning and refactoring, and then 2–3 days writing this post (I’m a slow writer).</p> | |
| <p>There were a few more things I wanted to try, but had to drop for lack of time:</p> | |
| <ol> | |
| <li> | |
| <p>Statecharts can have “extended state”, <a href="https://xstate.js.org/docs/guides/context.html">called “Context” in XState</a>. It looks like it would make sense to store the points and turn count in the <code>gameService</code>’s context.</p> | |
| </li> | |
| <li> | |
| <p>With the turn count stored in the <code>gameService</code>, the branching logic for going to the next turn <em>or</em> ending the game could be part of the state machine as well (instead of the <code>Playground</code> component’s state and the <code>startPhase</code> function). Probably using <a href="https://xstate.js.org/docs/guides/guards.html">Guarded Transitions</a>.</p> | |
| </li> | |
| <li> | |
| <p>I tried putting the playing phase duration config on the state machine, using <a href="https://xstate.js.org/docs/guides/states.html#state-meta-data">state meta data</a>, but it was awkward and created other issues for that use case.</p> | |
| </li> | |
| </ol> | |
| <p>Would I use XState on a new project? Definitely. Being able to reason about an app, screen or feature’s state by reading a statechart definition is invaluable, and the visualizations are a nice touch. And while I haven’t used most of the advanced features, reading up on them makes me confident that I could handle complex use cases.</p> | |
| <p>A word of caution though: when bringing XState to a team project, I’d factor in the learning curve for everyone involved. It’s probably worth doing some basic training, at least.</p></content> | |
| </entry> | |
| </feed> |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment