An HTML parser scans through an input string, starting at the beginning:
<div>hello<br>world</div>
│
└─ scanning begins here
Vacancy observers are a data-fetching strategy for functional UI frameworks which doesn't rely on side effects. Instead, components are written as pure functions, indicating their remote data dependencies directly in their output using vacancies.
An observer may then detect the presence of those vacancies and take appropriate action, depending on the environment. For example:
/* | |
* Using `motel` to implement a vacancy observer. | |
* This happens once at app startup time. | |
*/ | |
const motel = require('motel'); | |
const vacancies = motel(); | |
// start observing the DOM for vacancies | |
vacancies.connect(document.getElementById('#app')); |
/* | |
* <UserProfile/> React component which | |
* uses the vacancy observer pattern. | |
*/ | |
function UserProfile({ | |
userId, // comes from the URL | |
users, // collection of fetched items | |
}) { | |
const user = users[userId]; |
vacancies.listen('relatedProducts/:productId', async function(params, send) { | |
const id = params.productId; | |
const resp = await fetch(`/products/${id}/related`); | |
const products = await resp.json(); | |
send({ type: 'RECEIVE_RELATED_PRODUCTS', id, products }); | |
}); |
function ProductDetailPage({ viewportWidth, relatedProductInfo }) { | |
const hasRealestate = viewportWidth > 800; | |
const hasData = relatedProductInfo === undefined; | |
return <div> | |
... | |
{ hasRealestate && | |
( hasData | |
? <RelatedProducts products={relatedProducts}/> | |
: <div data-vacancy={`relatedProducts/${id}`}>Loading...</div> | |
) |
class ProductDetailPage extends React.Component { | |
componentDidMount() { | |
... | |
const hasRealestate = this.props.viewportWidth > 800; | |
const hasData = this.props.relatedProductInfo === undefined; | |
if (hasRealestate && !hasData) { | |
this.props.fetchRelatedProductInfo(this.props.productId); | |
} | |
} |
In which I get angry because some aspect of Elm seems... well, weird to me, and the docs aren't helping, so I jot down these notes in order to force myself to better grasp the topic, because writing forces me to think deeply about things in a way that I'm incapable of doing otherwise gaaasspp
The Elm architecture is cool because it's fractal. That is, you can break your program into components, each of which is a mini-expression of the overall Elm architecture. The Elm architecture is... turtles.
How is this done? I don't know! I'll figure it out and come back!
In which I get angry because some aspect of Elm seems weird, and the docs aren't helping, so I jot down these notes, because writing forces me to think deeply about things in a way that I'm incapable of doing otherwise gaaasspp
Building markup in Elm entails building a data structure, much like React's virtual DOM. That is, you're not building DOM nodes directly, but rather a lightweight data structure that tells the Elm runtime which DOM nodes you want to exist and it figures it out from there. There's really nothing special about Elm's Html
; it's just another data type.
In which I get angry because some aspect of Elm seems... well, weird to me, and the docs aren't helping, so I jot down these notes in order to force myself to better grasp the topic, because writing forces me to think deeply about things in a way that I'm incapable of doing otherwise gaaasspp
Background: In Elm, functions are pure. Given the same input, they'll always return the same output. That isn't the case in JavaScript, where for example a function can return different values on successive calls, like Math.random()
or Date.now()
.
Thus, a function that takes zero args is conceptually no different than a variable. A variable holds a value. A zero-arg function only returns one possible value. This is reflected in Elm syntax. Look at how you annotate and declare a variable in Elm: