Episode #3 Question: Advantages of your approach over a virtual-DOM approach? about episode-code-samples

[stephencelis]

Glad you enjoyed! @mbrandonw's on a flight somewhere over the ocean right now and may have his own thoughts, but I figured I could answer some of this for now.

Was this on your radar when you made the episode?

Virtual DOM ("virtual view hierarchy"? 🤔) and general Elm/incremental stuff has been on our radar for awhile now, but unfortunately fell out of the scope of this episode. We wanted to focus on showing plain old function composition in a practical "you can do this in your code today" kind of way (assuming you're allowed to introduce an operator to your code base—more on that in a future ep).

Do you think the approach you outlined has other advantages over this?

Mainly:

• That lack of friction: with a single function composition operation you're good-to-go.
• Avoiding the cost of distancing yourself too far from UIKit. It's probably easier to convince a team to use function composition with UIKit than jump ship for an entirely different model, where you maintain the interpreter or tie yourself to another third party.
• Although we love the testable benefits of the virtual DOM approach (you can get really great, low-cost snapshot test coverage of the hierarchical state of an entire screen by passing a "current state" to the DOM-producing function), what's nice about testing with actual view objects is you can get high-fidelity screenshot test coverage, and you can build playgrounds that act as living style guides!

Trade-offs! We'll be diving a bit deeper into composable view styling in an upcoming ep, and we'll definitely continue to explore wilder territory in the future!

Do you have any general thoughts on it?

Your example above is interesting and made me curious as to what it would look like with protocol composition! The final tagless approach might be fun to explore here and would allow us to avoid those downsides of inheritance or "object composition" using a view property. E.g.:

protocol View { … }
protocol Button: View { … }

Then we could have an interpreter for producing a UIKit hierarchy, and a separate interpreter for testing the hierarchy alone.

[stephencelis]

I should note that @bkase and @chriseidhof have been exploring this stuff a lot lately! Brandon Kase gave the view hierarchy example in his talk at dotSwift, and they've shown other examples of final tagless on Swift Talk. I'm looking forward to the community continuing to explore!

[mdiep]

Your example above is interesting and made me curious as to what it would look like with protocol composition! The final tagless approach might be fun to explore here and would allow us to avoid those downsides of inheritance or "object composition" using a view property

This is one of those examples that makes me wonder what it'd be like to live in a language like Elm that uses structural typing. 🤔