In general, if you are writing new code, you should avoid having to use the sync redraw at all.
Link to current Mithril documentation https://mithril.js.org/redraw.html
I'm not certain whether that call is still needed in the latest Flarum version. Flarum was originally written with Mithril beta, and since then Mithril has had 2 major updates, which Flarum followed. The current code is the result of converting older code to the newer Mithril syntax, but I'm not sure how recently we tested whether it was still needed.
Maybe someone else from the team will have a better idea, but some of the people who worked on that part of Flarum are no longer on the team, so some information might be lost to time.
Really that line should have been accompanied by a comment explaining why it was needed. We don't have inline comments, but luckily the git commit messages give us some hints flarum/frameworkeb0d3de
Later the call to m.redraw(true) was replaced with m.redraw.sync() when Mithril renamed the method in our big Mithril v2 rewrite flarum/framework2255
Here's what the commit message alludes to, if I remember correctly how it works or at least used to work:
Flarum has global helper methods used to control the text area, used for example by the Markdown toolbar to insert text in the current editor. But that helper is only created together with the actual HTML <textarea> in the discussion/reply composer component. If an extension wants to open a composer instance (show method) and immediately insert text in the editor, it wouldn't work because the composer component has only been scheduled to be redrawn (effectively drawn for the first time here) so the global helper is not available yet.
I'm not sure how much of this is still true in the current version of Flarum. But it's a bit of a hack. Ideally, the global helper should always be available, and itself should queue the commands it receives so that it can wait for the textarea to become available. But this would require a lot more code, and ideally also to rewrite most of that API to be asynchronous with promises for all getters. Calling a synchronous redraw to ensure the redraw happened immediately at the end of show() was the easiest fix. Another solution to this problem would be to keep the editor API synchronous, but make show() return a promise that will return when the Composer is actually rendered. But Mithril doesn't offer any API to implement this, we would have to use a system of inter-component callbacks or poll for the existence of the editor API helper.
So basically, there are usually more elegant and modern ways to solve the issues that m.redraw.sync() might fix. If the code is written to be asynchronous, it should never be needed in the first place.
Don't hesitate if you have any other question or if I made things too confusing 😇
