This is an extension to the already established MVVM pattern. As with most things, the use case for this extension is subject to the project you are working on and how you wish to organize your code. The classic MVVM pattern works just fine, but in this particular situation, the view models were doing lots of work and this was the motivation for introducing the Transform layer.
In general, good User Interfaces are lightweight and performs well and this is only feasible if the UI does minimal work. It’s job is to provide a gateway to more complicated operations behind the scene. Let’s assume for whatever reason, you need to do more work on the client side, work that is best suited to be done on the server and simply handed back to you. Let’s say that you have a situation where in order to show the data, you first need to grab different pieces of it from several services, assemble, pivot, get derived properties, etc. You can accomplish this following the MVVM pattern, but your VMs will become huge fast. Additionally, it’s mixing in too much business logic with UI specific properties. Also testing the VM becomes such a pain that you are motivated to find another solution.
After experimenting with a few different solutions, my team settled on the MTVVM (pronounced Empty V-VM if you want). The pronunciation of this acronym also states what we wanted, empty view models (well, not completely empty of course).
The idea was to simply abstract out the complex processing to a Transform layer that sits between the model and view model. In this way, we are able to keep the view and view model extremely light, which having a fully testable intermediary layer. By doing this, we can simply change complete verticals in the application without drastically impacting adjacent components.