If you are familiar with Haskell’s stm package, a LVar is essentially a TMVar but with an extra ability for other threads to observe changes. Ema uses it for hot reload, and your application code is expected to set and update its model through the LVar.
Documentation on LVar is available on Hackage.
For monitoring local files on disk you would typically use something like fsnotify in place of observeFileSystem. What is the point of doing this? To support hot reload on data change. Imagine that your static site is generated based on Markdown files as well as HTML templates on disk. If either the Markdown file, or a HTML template file is modified, we want the web browser to hot reload the updated HTML instantly. This is enabled by storing both these kinds of files in the application model and using LVar to update it over time.
mountOnLVar “mounts” the files you specify onto the model LVar such that any changes to them are automatically reflected in your model value.
The runEma function is explained here, but in brief: it takes a render function (see below) as well as an IO action that allows us to create and update the model lvar. Note that threadDelay maxBound here? That is because our IO action must not exit; in the dev server mode of real-world websites, you would continue to monitor the external world (such as Markdown files) and update the model, to facilitate hot reload of data used by your site.
For anything outside of the Haskell code, your code becomes responsible for monitoring and updating the model LVar. The `unionmount` library already provides utilities to facilitate this for monitoring changes to files and directories.
Ema’s dev server supports hot reload; it will observe changes to your model, in addition to code. To facilitate this you will manage your model as a LVar. The runEma function (described here) takes an IO action that gets LVar model as an argument.