Migration docs: elaborate on changes in redraw logic (#1440)

* Migration docs: elaborate on changes in redraw logic

* Removed bad m.request().then(m.redraw) docs

docs/change-log.md

@@ -13,7 +13,9 @@ If you are migrating, consider using the [mithril-codemods](https://www.npmjs.co
 - [`m.prop` removed](#mprop-removed)
 - [`m.component` removed](#mcomponent-removed)
 - [`config` function](#config-function)
-- [Cancelling redraw from event handlers](#cancelling-redraw-from-event-handlers)
+- [Changes in redraw behaviour](#changes-in-redraw-behaviour)
+   - [No more redraw locks](#no-more-redraw-locks)
+   - [Cancelling redraw from event handlers](#cancelling-redraw-from-event-handlers)
 - [Component `controller` function](#component-controller-function)
 - [Component arguments](#component-arguments)
 - [`view()` parameters](#view-parameters)
@@ -118,7 +120,15 @@ If available the DOM-Element of the vnode can be accessed at `vnode.dom`.
 
 ---
 
-## Cancelling redraw from event handlers
+## Changes in redraw behaviour
+
+Mithril's rendering engine still operates on the basis of semi-automated global redraws, but some APIs and behaviours differ:
+
+### No more redraw locks
+
+In v0.2.x, Mithril allowed 'redraw locks' which temporarily prevented blocked draw logic: by default, `m.request` would lock the draw loop on execution and unlock when all pending requests had resolved - the same behaviour could be invoked manually using `m.startComputation()` and `m.endComputation()`. The latter APIs and the associated behaviour has been removed in v1.x. Redraw locking can lead to buggy UIs: the concerns of one part of the application should not be allowed to prevent other parts of the view from updating to reflect change.
+
+### Cancelling redraw from event handlers
 
 `m.mount()` and `m.route()` still automatically redraw after a DOM event handler runs. Cancelling these redraws from within your event handlers is now done by setting the `redraw` property on the passed-in event object to `false`.