Pure UI

I&#x27;ve noticed the f(data) = view paradigm dominate the clojurescript landscape ever since om and reagent[1]. There&#x27;s also a library that literally uses function calls and parameters for every piece of UI called re-frame[2] (which also has a badass readme).<p>Using pure functions to compose a UI along with keeping all the data in one place have been a huge win for our project for a few reasons.<p>1. All it takes to debug what a handler is doing is what effect it has on the DB. Our handler functions are also mostly pure functions which take the current-db as a parameter.<p>2. We can serialize the state to local storage (or a string) and reload it from local storage (or a string).<p>3. Using the repl, we can investigate the state of the application while it&#x27;s running.<p>[1] <a href="http:&#x2F;&#x2F;reagent-project.github.io" rel="nofollow">http:&#x2F;&#x2F;reagent-project.github.io</a> [2] <a href="https:&#x2F;&#x2F;github.com&#x2F;Day8&#x2F;re-frame&#x2F;" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Day8&#x2F;re-frame&#x2F;</a>

I just think that automatically-updating &quot;views&quot; counter is awesome. A little distracting, but cool to watch it update in real-time.

What&#x27;s old is new. Silverlight had a big focus on declarative UI that continues to today with XAML: <a href="https:&#x2F;&#x2F;msdn.microsoft.com&#x2F;en-us&#x2F;expression&#x2F;cc941385.aspx" rel="nofollow">https:&#x2F;&#x2F;msdn.microsoft.com&#x2F;en-us&#x2F;expression&#x2F;cc941385.aspx</a>

This is exactly the approach Elm takes. The recommended way to structure the application is so that the view is a pure function of the Model (application state). Moreover, the change to application state is also pure: there is a pure function that takes an event and an old model, and then returns the new model.<p><a href="http:&#x2F;&#x2F;elm-lang.org&#x2F;guide&#x2F;architecture" rel="nofollow">http:&#x2F;&#x2F;elm-lang.org&#x2F;guide&#x2F;architecture</a>

This ability to concretely display a component in all of its different states is one of main reasons I created devcards (ClojureScript, Figwheel). One can use it to create storyboards live as you are programming.<p><a href="http:&#x2F;&#x2F;rigsomelight.com&#x2F;2014&#x2F;06&#x2F;03&#x2F;devcards-taking-interactivity-to-the-next-level.html" rel="nofollow">http:&#x2F;&#x2F;rigsomelight.com&#x2F;2014&#x2F;06&#x2F;03&#x2F;devcards-taking-interacti...</a><p>I have been putting a lot of work into devcards lately so forgive me for being so focused on it.<p>:)

This.<p>1. Create pure UI component<p>2. Describe allowed state space as DSL&#x2F;type - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=8963000" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=8963000</a><p>3. Plug in fuzzer<p>4. Watch till you catch an undesigned state<p>5. Fix &amp; repeat

Help me understand some of this stuff:<p>&gt; the definition of an application’s UI as a pure function of application state<p>I presume &quot;application state&quot; means the stuff that the app cares about, and not the stuff that it doesn&#x27;t.<p>But the app&#x27;s actual, rendered UI incorporates state from multiple sources. For example, if you have a text field, it has &quot;application state&quot; like its positioning, &quot;framework state&quot; like where the text selection(s) are, &quot;user state&quot; like what size the user dragged it to, etc. And your &quot;pure function of application state&quot; necessarily discards this non-application state.<p>So then how does this state ever get preserved? The answer must lie in the &quot;diffing algorithm:&quot; the thing that determines what has changed, and attempts to reuse as much of the old UI as possible. A good algorithm will reuse an element and preserve its state. A naive algorithm will drop state and result in bad UI.<p>So in this model, aren&#x27;t you taking a huge and hidden dependency on this diffing algorithm? What&#x27;s the right way to ensure continuity of non-application state across updates?

Thanks for the essay, it was a great read. Maybe my understanding is wrong, but I am slightly perplexed by one idea. I really like the link you have created between the designer&#x27;s and developer&#x27;s workflow, and I think your essay touches on an ideal. But, from an applied perspective, this may be difficult to attain when creating components that need to visually transition between state within the original element.<p>Using your video player example, if the video is loading (state 1), and once loaded, it starts playing (state 2), wouldn&#x27;t a pure functional approach imply the entire &lt;video&gt; DOM element is replaced by a new one in the change from state 1 to state 2? What if I only wanted to animate the loading bar away and fade out the thumbnail when leaving the loading state, while maintaining the original HTML element?<p>I&#x27;m curious to know if you&#x27;ve thought about this, and have any insight, because it&#x27;s something I hope to understand. Thanks.

I like the idea of having pure functions f(state)=view, however, wouldnt this be very slow for very big ui applications? Also the only reason todo this on web is to use some sort of double-buffering and prevent redraws before everything is updated. On mobile native you have control over these things. But thinking about it, doing purely functional UI for native apps would never work, right? You need todo a dif each and every time the ui updates. And this happens a lot for example for sliders, or animations.<p>Is the approach inherently flawed for fast UI applications?

&gt;In general, comparing frameworks in terms of features seems inferior to examining the model it imposes on the programmer. The latter will inform you about how well the code will fare over time as the product matures and the team grows, but the former won’t.<p>I feel like this is a much more semantic interpretation of frameworks than trying to compare the likes of Angular, React, or JsBlocks on speed, data-binding, and whether they support x,y,z use cases. Kudos rauchg.

Reminds me heavily of React. Components that render 1 single thing based on the current state of the component.<p>Building out my UI with Meteor and React was so cool, I found myself having fun again.

Another take on the idea of finding the complete specification is Parnas Tables. <a href="https:&#x2F;&#x2F;cs.uwaterloo.ca&#x2F;~jmatlee&#x2F;talks&#x2F;parnas01.pdf" rel="nofollow">https:&#x2F;&#x2F;cs.uwaterloo.ca&#x2F;~jmatlee&#x2F;talks&#x2F;parnas01.pdf</a><p>I&#x27;m thinking it could be interesting to combine some agile technique like ATDD and user story mapping with such a disciplined formalism.

How would one code, e.g., a rich text editor using such an approach? And would it be able to handle texts, of say, hundreds of pages?

Indeed. You can roll your own without React. Simply indicate when something changed in your model, and update the DOM on the next frame using a PURE state -&gt; DOM mapping function.<p>What do you y&#x27;all think of something like this?<p><a href="http:&#x2F;&#x2F;platform.qbix.com&#x2F;guide&#x2F;tools#dom" rel="nofollow">http:&#x2F;&#x2F;platform.qbix.com&#x2F;guide&#x2F;tools#dom</a>

For those cordial with CoffeeScript, there&#x27;s Hamlet[1] (which is based on&#x2F;inspired by HAML[2]). It&#x27;s a pretty nice declarative-esque UI library. From their home page, here&#x27;s a sample:<p><pre><code> %label Search: %input(value=@search type=&quot;text&quot;) %label Sort by: %select(value=@sortBy @options) %ul -each @sorted, -&gt; %li.phone(@class) %img(@src) .name= @name .description= @snippet </code></pre> 1 - <a href="http:&#x2F;&#x2F;hamlet.coffee" rel="nofollow">http:&#x2F;&#x2F;hamlet.coffee</a><p>2 - <a href="http:&#x2F;&#x2F;haml.info" rel="nofollow">http:&#x2F;&#x2F;haml.info</a>

The convergence of the designer and programmer roles feels, if you&#x27;ll pardon the pun, like React&#x27;s one-way data flow: moving from design to programming.<p>Of course, the ecosystem will build better tooling to support less technical folks, but for now it&#x27;s still heavily engineering-focused.

Now, it would be interesting to see how <i>function pay()</i> should be written with the new approach and how it evolves when the new states (&quot;network went away error&quot;, &quot;must be logged in&quot;, &quot;certain role&quot;, &quot;pre-existing data&quot;) are discovered.

I wasn&#x27;t able to read any of this because of the stupid fucking flashing view counter at the top of the page.<p>View counters have been dead for a long time and need to stay that way. No one cares how many views you have and certainly no one wants to have a flashing box at the top of the page they&#x27;re trying to read.