At the end of April, I gave a talk about Om Next at Craft Conf in Budapest. The talk was recorded and the link is below.

Although a standard routing solution is an orthogonal concern to Om Next's design and, at the time of this writing, there is still ongoing development with the objective of introducing simpler routing hooks, there are already several ways in which one can add proper route navigation to an Om Next app. This post aims to decrease the general community confusion around this topic by introducing a variety of different approaches that can be used to integrate routing in an Om Next app.

In a recent post, I've put together a checklist covering the steps involved in writing reloadable Om Next code. If you are trying to use them in your devcards, however, you might find that current Devcards helpers for Om Next are still lacking full support for a pleasant, out-of-the-box reloadable experience, even when sticking to every recommendation in that list. Enter `devcards-om-next`.

It didn't take long since Figwheel came into our ClojureScript environments for it to become a crucial part of our development workflow. Its code hot loading magic provides the basis for an easy, enjoyable interactive programming experience. The rest — writing code that can be repeatedly evaluated without disturbing our running program's state — is up to us. In this post I will go through what you need to know to start writing reloadable code in Om Next.

This is part two of a series of posts that aim to demonstrate how to build classical Software Engineering object recursion patterns in Om Next. In the previous post, we explored the Om Next constructs of the Composite. This time around we will use the Decorator design pattern to build a simple component hierarchy that provides runtime extensibility.