lucaquerella

It's quite long to explain it here, why don't you take a look at the Node.swift source code, if you have trouble understanding a specific part I'll be happy to help you.

It's Void. In that example there is no need for the action to have a payload.

I don't blame you for being skeptical.

The main advantages we've noticed using this pattern are:

1) every time there is a crash or a problem we can look at the the state and the actions that lead to that situation. This improved our ability to spot and fix bugs.

2) we can easly reproduce any appearance of the UI by providing a struct the rappresents the state of the app. This has improved our ability to QA the entire UI quickly.

3) with this architeture we've been able to refactor the code in simpler unit of logic rather then creating big VC. This has improved the readibility of our codebase.

4) it's easier to reason about the UI with the Katana (that is, declarative) approach rather than having to handle mutations

I'm not saying this is a solution for every problem but I can tell you that we internally used it and liked a lot so we felt like sharing our work with the world :)

It may be an overkill for super simple apps with just few views. But it works great with a larger codebase, at least for us. We have apps built with it with hundreds of views and it works great, it has halved our development time and helped us to have a more structured and clean approach to the state management.

Yes, absolutely. You can use it to implement a single view or the entire app. Just render a NodeDescription in an existing UIView.

EDIT: https://gist.github.com/lucaquerella/74d8bbb5855f26249a27b4a...

I'm one of the author of the framework :) please let me know if you like our approach to apps development we internally use it for creating our own apps at Bending Spoons (http://bendingspoons.com)