Mihael Konjevic ClojuTRE 2017 Interview

Mihael Konjevic will be giving a talk at ClojuTRE 2017. His talk is called Developing (with) Keechma.

Follow him on his Homepage, GitHub and Twitter.

PurelyFunctional.tv: What is your favorite feature of Clojure?

Mihael Konjevic: If I would have to pick one, it would be immutable data structures. I'm mostly programming frontend applications, and it's crazy how much productive and care free I feel since I've switched to ClojureScript. I was working on a big TypeScript application last year, and the first mind boggling bug that I've introduced was related to mutability. For me immutable data structures are a 100% win.

PF.tv: What is your least favorite feature of Clojure?

MK: Debugging can be painful. After a while you get the feeling where the problem might lie, but it was a huge pain when I was beginning.

PF.tv: Can you briefly describe your talk?

MK: I will talk about the Keechma (frontend) framework and why it exists. Before doing ClojureScript I was a core contributor to the CanJS framework, and I when I started working on my app (in Re-frame and Reagent), I've felt that there were a lot of things missing. The fundamentals were great, but I had to manually take care of a lot of stuff that CanJS had solved out of the box. First cut of Keechma was built inside the codebase of that app, but then I've decided to extract it, document it and release it as a separate project. In this talk I'll cover the pains that Keechma is fixing, and how and why I've fixed them in a way that I did.

PF.tv: Why did you choose this topic?

MK: Every framework is a formalized set of it's authors' beliefs, so I wanted to talk about these beliefs and how they make frontend development easier, simpler and more deterministic.

PF.tv: What is one thing I will be able to do after watching your talk?

MK: My goal #1 is to motivate people to try Keechma, but I want to do it in a way where I present the decisions behind it. Even if you don't try Keechma afterwards, you will have more in depth understanding of the tradeoffs that are made when building a framework.

PF.tv: What are the three most important concepts I need to know to follow the conversation?

MK: Experience with any similar framework - like Re-frame or React

  • Redux should be enough to allow you to follow the talk. My plan is to talk about the philosophy behind Keechma, so it's useful if you are familiar with different approaches to the same problems. If I would have to pick three most important principles in Keechma they would be:
  1. Unidirectional data flow
  • Route params are derived from the URL
  • Application state is derived from the route params & UI is derived from the application state
  1. Automatic synchronization of entities' states
  • An entity is any data loaded into the app that has identity (e.g. :id column)
  • Entities are stored in the EntityDB (Keechma sub library)
  • EntityDB propagates entity state to every place where that entity is displayed in the UI
  1. Enforced lifecycle (and memory safety)
  • Automatically load data on route change
  • Automatically clean up stale data on route change
  • Automatically set up event listeners on route change (e.g. listener on the WebSocket)
  • Automatically tear down event listeners on route change

PF.tv: Where can people follow you online?

MK: They can find me on Twitter and on GitHu.

PF.tv: Are there any projects you'd like people to be aware of? How can people help out?

MK: Yeah, checkout Keechma :) and if you're into GraphQL. Also, if you tried to use Keechma let me know what were your pain points - conceptually or documentation wise.

PF.tv: What one feature from another language would you like to see in Clojure?

MK: Maybe I'm still in the honey moon phase with Clojure, but I don't feel like there's anything missing in the language.

PF.tv: What is your favorite Clojure function or macro?

MK: I'd say go blocks. They powers a lot of internal code in Keechma and Keechma Toolbox where more imperative style is appropriate. It is great to have it at disposal when needed.